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