On Sun, Jun 02, 2019 at 12:38:24AM -0400, Public mailing list for Arch Linux development wrote:
Dear Christian,
Thank you for your email.
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)?
Well, my proposal was to remove bureaucracy, not to add more bureaucracy. Here are various issues that I had in the past: 1. I am waiting since weeks for a separate section for legal related content in our dev wiki for adding the AUR takedown request answer template. This template was created by awesome team work and I think it would be sad if it would be just gone. Furthermore people said that it would be a good idea to have it somewhere for future takedown requests. 2. At the moment it's difficult to co-maintain packages between [extra] and [community]. A developer who wants to allow co-maintainership by TUs needs to move a package to [community]. In my opinion this step is unnecessary and leads to unnecessary communication and workflows. 3. I don't like that devs and TUs live aside each other instead of finally realizing themselves as community or group. I think the community as itself would work much better if we would have user-access based package repositories and just 'maintainers', instead of this dev/TU split.
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.
What interests me is why is this whole process not transparent and public? I mean we discuss adding new TUs publicly. Of course this dicussion comes with all its good and bad parts, but atleast it's transparent and people get a reason why they are not elected. I am a big fan of the 'people can change' attitude, but this only works if they know their mistakes. The only reason for private discussions seems to be 'personal bias'. Atleast thats what I think if I think about private elections or better selections of new devs. And personal bias should never a criteria to select or deny somebodys contribution, it should be based on technical questions.
The idea of having a separate repository for (most) proprietary sounds sensible to me.
I have a few things to add regarding proprietary software, that we have discussed in IRC. It would be nice to have atleast a list somewhere with proprietary software and their license. I mean we can be glad, that the TU asked for adding vivaldi browser to community, what if he would have just added it? I guess it wouldn't be a problem, until somebody finds it or we get a take down request for the package. Therefore I wonder how many packages we may illegaly redistribute already? Maybe it would be useful to track such packages somehow and a separate repository would be a good starting point for this.
Is there any hidden suggestion here?
Yes, a suggestion for user-isolated packages. This will be/can be achieved via the move to a git repository.
I am confused. You are saying we are mixing too many roles above and suggesting to reduce the number of roles now?
Well, I guess it's not possible to simplify all rules. But we could at least start with simplifying the role of package maintainers and start realizing us as one community not as two separate groups.
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.
A kanboard does exist already for it, and I hope more will be discussed at meetups.