[arch-dev-public] Proposal for a new organisation structure

Sat Jun 1 23:08:30 UTC 2019

Hello everybody,

----------------------------
DISCLAIMER:
Sorry for the huge mail, I didn't thought it would get so long. If you
feel attacked/angry or whatever about it, take a deep breath before you
answer. I hope for a constructive discussion without personal attacks.
----------------------------

inspired by the last thread about moving proprietary software to
community, our general problem of getting more people involved in Arch
Linux and the (for me) chaotic organisation structure and hierarchy I
would like to propose a discussion about changes.

Please don't see this thread as an attack on your current position or
whatever.

I would like to propose a more democratic, simplified and more
contribution friendly approach for our current hierarchy and
organisation structure.

At the moment we have the following three Groups (If I miss something feel
free to correct me):

- Devs
- Trusted Users
- Support Staff

These three groups have the following 'features' and tasks:

- Devs:
  - Tasks:
    The developers care about [core] and [extra] repositories, they form
    a direction for the whole project 'arch linux' and they seem to have a
    veto-permission for TU decisions. Furthermore they have access on most
    infrastructure and they are maintaining/developing the core software
    like pacman. Some devs also care about trademarks, legal requests
    and finance or community events.

  - How to be a developer?:
    The developers will decide in a non public and secrete ritual who is
    worthy to be a developer. The process is unclear.

- Trusted Users:
  - Tasks:
    The trusted users care about the [community] repository, somehow some
    TUs have more tasks like: security team involvement, wiki
    administration, infrastructure administration, maintainership of
    software projects and other infrastructure projects like docker
    images, reproducible builds etc. Furthermore they care mostly about
    the package quality in the AUR (eg. answering submitted requests...)

  - How to be a trusted user?:
    It's well documented, we have rules for misbehavior, rules for
    applying, guidelines for moving packages into community and more.

- Support Staff:
  - Tasks: They do various tasks like infrastructure administration,
    wiki administration, bug wrangling, software contribution, forum
    moderators, security team, but they have no access to any
    repository.

  - How to be a support staff:
    It's unclear, mostly a new contributor just knows the right people
    and does the right thing at the right time and get somehow
    acknowledged by developers or TUs for their work.

Ok, I hope this gives a good overview over all three groups. Besides
these groups, we have also people in more than of these groups. Anthraxx
is for example listed as (dev,tu and support staff) on our website, I am
listed as (tu and support staff) and so on.

So what is my actual proposal. Well my proposal is to simplify the whole
organisational structure, tear down bureaucracy, tear down 'walls' and
unify the community  and make it easier for
'outsiders' to contribute to the project we all love.

Therefore I would like to propose a discussion around the following
things:

1. Simplified repositories

Currently we have [core], [extra] and [community]. These three
repositories are there, because they have grown to this structure over
time. At the moment I don't see any real meaning for the split of [core]
and [extra]. So one suggestion would be to either:
  - merge [extra] and [core]
  - or use [extra] for a new purpose, like for example a proprietary
    repository, for all proprietary software. (I know that this is not
    possible for all packages, because we have binary blobs in device
    drivers and kernel modules).

2. Repository access

At the moment a TU can access all packages inside of the [community]
repository. Therefore they are able to modify packages in a good or bad
manner. This can have nice effects and bad effects, how the past has
shown to use, such as:
  - rapid updates in case of security vulnerabilities (good effect)
  - updates of packages, because somebody thought it needs an update,
    but the real reason for the delay was a bug inside of the new
    version of a software (bad effect)

3. Organisation structure

Depending on the repository access, we could reduce our organisation
structure to just two groups: Devs and maintainers (a similar approach
to big distributions like Debian). Devs could still have the
'superpower' for caring about infrastructure and legal/finance stuff and
the group of trusted users and support staff would merge to one group of
maintainers. With person-related access to package repositories we could
tear down the whole repository structure to one, maybe two, repositories
and we could give co-maintainership an actual meaning (permission to
modify a foreign package).

4. More transparency

At the moment the recruiting process for developers is pretty unclear,
as well as the actual decision making inside of the developers group,
veto permissions and other things. This leads to a 'they vs/with us'
thinking and makes it difficult to increase contribution in the
community. Therefore I would like to propose more transparency for
all groups who are involved in Arch Linux development and more
communication between devs and TUs. At the moment the devs will mostly
say:"Ok, this is a TU thingie, so I don't need to get involved in this
question regarding TU rules or rules for community or anything else".

It would be also nice to form an actual roadmap (yes.. I know.. we are
not a company, but a roadmap or overview over all current projects
inside of our community would be nice). This way it would be also easier
to contribute for 'outsiders'.

Sorry for the huge mail, I didn't thought it would get so long. If you
feel attacked/angry or whatever about it, take a deep breath before you
answer. I hope for a constructive discussion without personal attacks.

Best regards and many thanks for reading the whole mail,

shibumi / chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20190602/7702aa5e/attachment-0001.sig>