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

[Lukas Fleischer]

Dear Christian,

Thank you for your email.

On Sat, 01 Jun 2019 at 19:08:30, Christian Rebischke via arch-dev-public wrote:
> 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.

I do not share your point of view that the organization is chaotic. You
successfully explained the three roles and each of its duties within two
or three clear sentences. We could certainly have a more fine-grained
hierarchy but our team is not very big and I personally do not think the
benefits would outweigh the extra administrative work in the long run.

Do you have any concrete evidence that adding more bureaucracy would
benefit the project? Any evidence that our current organizational
structure prevents people from contributing (which you seemed to imply
with your statement above)?

>   - 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.

As Gaetan already mentioned, the process is clear: somebody suggests a
new developer and we discuss until a consensus is reached. Feel free to
document that somewhere in our wiki if you think it needs to be
documented. If you have specific concerns with that process, feel free
to share them. However, I do not think anybody in the dev team ever had
any objections against that procedure.

>   - 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).

The idea of having a separate repository for (most) proprietary sounds
sensible to me.

> 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)

Is there any hidden suggestion here?

> 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).

I am confused. You are saying we are mixing too many roles above and
suggesting to reduce the number of roles now?

> 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".

We made the process transparent already. Again, feel free to document it
in a more "accessible" place.

If you think these discussions should be public, please explain why.
Most of the time, it is just a suggestion and a bunch of "+1", so
nothing exciting there. And *if* a developer ever brings up a concern
with somebody not being suited for the team due to, say, personal
concerns or inappropriate behavior, I guess that candidate would prefer
having that issue discussed in private.

> 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'.

Does not sound like a bad idea to me. Feel free to create a draft.

Best regards,
Lukas