[arch-dev-public] Proposal for a new organisation structure
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
Hi Christian, [2019-06-02 01:08:30 +0200] Christian Rebischke via arch-dev-public:
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 seem to recall we've had a similar discussion just a couple of months ago but allow me to reiterate some key points. First, contrary to what you keep saying, the process by which devs make decisions is very clear: by discussing things until a consensus emerges. In extreme cases where a consensus cannot be reached, we can take a vote or let our leader decide, but this has never happened in the nine years I've been a dev. To the best of my knowledge, we're all very happy with this system and do not want to change it. Second, our current organizational structure has served us well for many years. What problem are you trying to solve by overhauling it? What piece of evidence do you have that your suggestions will fix those problems? I'm certainly going to support imposing more bureaucracy just for the sake of bureaucracy. Again, if a certain system works for TUs, I'm glad and I'm certainly not going to impose my views on how TUs work; after all, that's why the TUs were made a self-governing body. Cheers. -- Gaetan
On Sat, Jun 01, 2019 at 04:10:45PM -1000, Public mailing list for Arch Linux development wrote:
Hi Christian,
[2019-06-02 01:08:30 +0200] Christian Rebischke via arch-dev-public:
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 seem to recall we've had a similar discussion just a couple of months ago but allow me to reiterate some key points.
First, contrary to what you keep saying, the process by which devs make decisions is very clear: by discussing things until a consensus emerges. In extreme cases where a consensus cannot be reached, we can take a vote or let our leader decide, but this has never happened in the nine years I've been a dev.
Hi Gaetan, Thanks for your mail. I remember now that you have told me this some months ago. This leads to a question: Why are these types of dicussions not public?
I've been a dev. To the best of my knowledge, we're all very happy with this system and do not want to change it.
Who do you mean with 'we'? Are you sure you speak for all devs and TUs here?
Second, our current organizational structure has served us well for many years. What problem are you trying to solve by overhauling it? What piece of evidence do you have that your suggestions will fix those problems? I'm certainly going to support imposing more bureaucracy just for the sake of bureaucracy. Again, if a certain system works for TUs, I'm glad and I'm certainly not going to impose my views on how TUs work; after all, that's why the TUs were made a self-governing body.
Well, that's point. I don't really think the current system works as it could be. Why being happy with the current state of organisation if we could achieve much more with a more simplified and more contributor friendly model? And this 'self-governing body' is exactly what I don't like. It increases this 'we and them' like thinking. Furthermore my suggestions are not the best solution, it was just a start for discussing our current structure. If you and the others see no point in changing the current structure this is totally fine, I just think it's important to rethink processes from time over time.
Cheers.
-- Gaetan
[2019-06-02 06:06:35 +0200] Christian Rebischke:
On Sat, Jun 01, 2019 at 04:10:45PM -1000, Public mailing list for Arch Linux development wrote: Thanks for your mail. I remember now that you have told me this some months ago. This leads to a question: Why are these types of dicussions not public?
Our discussion some months ago was public, just like this one. Most discussions among devs are public. Some aren't because we feel certain sensitive topics are better discussed in an environment where nobody is afraid to speak their mind. That includes topics like the addition of new developers, although like Lukas said in most cases those solely contain positive support for the proposal. Again, to the best of my knowledge, all devs are very happy with this process and do not want to change it.
Well, that's point. I don't really think the current system works as it could be. Why being happy with the current state of organisation if we could achieve much more with a more simplified and more contributor friendly model?
Feel free to explain what does not currently work as best as it could, what could be simplified, what could be more contributor friendly, etc. If you discussed specific problems, we could all have a go at proposing solutions a little more realistic than overhauling our organisational structure...
If you and the others see no point in changing the current structure this is totally fine, I just think it's important to rethink processes from time over time.
What I think is most wrong with your current and previous "proposals" is that you obviously don't understand how the present dev system works, yet you want to change it! Have some humility, man, and remember this system has worked for about a hundred devs and for over a decade. Cheers. -- Gaetan
On 6/1/19 7:08 PM, Christian Rebischke via arch-dev-public wrote:
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.
Core software like pacman... no one maintains pacman except for Dave, Allan, and Andrew. Being a dev does not give you authority to maintain or develop core software, being the appointed caretaker of core software gives you that authority. I'm a frequent contributor to pacman, despite being only a TU. I, a TU, am also the maintainer and developer of a different core infrastructure -- dbscripts. This is mainly because I volunteered to do so. Jouke Witteveen is the maintainer and developer of netctl, which is apparently our blessed networking utility and even distributed in [core] and as part of the official installation media and install process (not to knock his great work, but I still don't understand this choice :p as my attempted bug report to add networkmanager to the archiso should prove). Jouke is neither a TU nor a Dev, his only responsibility to the Arch Linux project is as the netctl project lead. On the topic of infrastructure, there are currently 37 Developers, and a mere 9 of them have access to the infrastructure. I'm not positive about this, but think one or more of these 9 may have been there since before being accepted as a Dev. The 10th person with infrastructure access does happen to be a forum moderator, but is not a Dev or a TU, and seems to be happy with his current level of contribution (which is admittedly mighty).
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).
Nope nope nope. The division between [core] on the one hand and [extra]/[community] on the other, is described here: https://wiki.archlinux.org/index.php/Official_repositories#core And there's pretty good and inviolable reasons for the split -- it makes no sense to try merging it with anything else. It's unrelated to who has access to package there -- but it does make some sense to restrict packaging for [core] to the core project Devs. Whether the split between [extra] and [community] makes sense is another topic, one which could, I guess, be argued. In that case, it's a lot more accurate to describe it as "two repos that are mostly similar in terms of what software goes there, with nebulously defined boundaries except for the former being restricted to only Devs".
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)
I'd *probably* argue that "somebody thought it needs an update" is not really a wonderful reason to bump someone else's package without at least trying to contact them and e.g. ask "can I bump this and help you comaintain it, because I use it and would like to help take care of it".
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).
Not sure I quite understand why support staff and maintainers need to be merged, though. For example, just because someone is given keys to the wiki doesn't automatically mean you also want to give them access to a packaging role.
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".
Which sort of makes sense, I guess, at least inasmuch as a Dev can also be a TU and there are a number of people who are both, because theu're interested in and involved in TU thingies.
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'.
Roadmaps sound neat, but the question becomes "what to put in them". :p Very often, when someone has an itch to scratch about something that needs to be done, they just do it. Do-ocracy at its finest. :) That being said, I guess this would be a good time to remind everyone... we now have a Kanboard for "general" issues pertaining to making Arch Linux better: https://kanboard.archlinux.org/public/board/964f9d8069094e955512b8edf75d2bb4... Anyone who wants access to this board should please contact the devops team for a kanboard account. -- Eli Schwartz Bug Wrangler and Trusted User
On 2/6/19 9:08 am, Christian Rebischke via arch-dev-public wrote:
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]
I stopped reading here. If you don't understand the difference between [core] and [extra], you should ask. Particularly before proposing the removal of [core]. Allan
On Sun, Jun 02, 2019 at 01:07:12PM +1000, Allan McRae wrote:
On 2/6/19 9:08 am, Christian Rebischke via arch-dev-public wrote:
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]
I stopped reading here. If you don't understand the difference between [core] and [extra], you should ask. Particularly before proposing the removal of [core].
Allan
Hi Allan, I didn't propose the removal of [core], I proposed a discussion around the current repository and organisation structure. Merging [core] and [extra] is just one of many ideas. If you have something to say, please do so and don't keep your secret. I would be glad if you could share it. chris
On Sun, 2019-06-02 at 05:55 +0200, Christian Rebischke via arch-dev-public wrote:
On Sun, Jun 02, 2019 at 01:07:12PM +1000, Allan McRae wrote:
On 2/6/19 9:08 am, Christian Rebischke via arch-dev-public wrote:
1. Simplified repositories Currently we have [core], [extra] and [community]. These threerepositories are there, because they have grown to this structure overtime. 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]
I stopped reading here. If you don't understand the difference between[core] and [extra], you should ask. Particularly before proposing theremoval of [core]. Allan
Hi Allan,I didn't propose the removal of [core], I proposed a discussion aroundthe current repository and organisation structure. Merging [core] and[extra] is just one of many ideas. If you have something to say, pleasedo so and don't keep your secret. I would be glad if you could share it. chris
Hello, [core] packages must land in [testing] and receive signoffs before reaching [core].In other words, packages in [core] must receive positive feedback before a wider diffusion.This introduce a latency to lower the risk of base components breaking. So, before merging [core] and [extra] we should have a way to flag packages which requires signoffs. Secretly, Sébastien "Seblu" Luttringer
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
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.
On 3/6/19 2:39 pm, Christian Rebischke via arch-dev-public wrote:
3. I don't like that devs and TUs live aside each other instead of finally realizing themselves as community or group. The TUs are set up as an independent organisation with their own bylaws. Many of those bylaws were implemented to keep independence from the developer team. Saying that, almost all developers have been a Trusted User, and there is a decent overlap currently. I mostly see this as a responsibility divide.
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.
I agree that the distinction between [extra] and [community] is rather limited. I think we need a better definition of what [extra] is, and move packages that don't fit that definition out of [extra] and into [community] where both devs and TUs can maintain them. Or even merge those two repos.
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.
You are very much overthinking what goes on when deciding on a new developer. "Electing" a developer is very different than electing a TU. People given developer positions have probably been around for years and are already doing the job before they get formally offered it. So it is a case of someone saying "this person should be a developer" and the rest going "OK". There is usually no discussion, because the candidate is well known already, and has obviously been doing a good job to even be nominated. Having TU style discussions on the suitability of a candidate makes no sense in that situation. Allan
Em junho 1, 2019 20:08 Christian Rebischke via arch-dev-public escreveu:
---------------------------- 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. ----------------------------
Ok. Here we go.
At the moment we have the following three Groups (If I miss something feel free to correct me):
- Devs - Trusted Users - Support Staff
The lines are not that clear cut, but in a general sense we have those 3. At least that's what's on our website, so I'll give you that. I'm a perfect example of why this is not always the case.
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.
Devs can also care about [community], if they are also a TU. Also, regarding what you said about veto, there's no such thing. Yes, devs *can* have a final say on stuff, but that's different from vetoing it. A veto, by definition, means no discussion at all. I don't recall ever some dev simply saying something wouldn't happen and no discussion regarding it. Also, common sense applies here (you can't get it on writing though). Regarding infrastructure, the devops team has access to the infrastructure, but that doesn't mean dev's have access by default. Yes, a lot of people on the devops team are dev's, but it's not a requirement, at all. I've applied to TU, to only then learn about the devops team. I would probably started contributing there first, instead of applying to TU if I learned about it sooner. By the way, this brings back the discussion about having a one stop page for contributions.
- 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.
There's no ritual. One of the things I did after becoming a dev was to go through arch-dev's archives. I didn't saw any arcane rituals or goat sacrifices. It's basically: Hey, let's promote X to dev? +1. Some discussion might ensue, but it's rare and I never saw one promotion that didn't go through in these years I've been dev.
- Trusted Users:
I'll skip, you described this accurately.
- 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.
Just to point out that some staff have access to a lot of stuff. Even if it's not clear immediately.
- 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.
Mostly because staffers are doing the work nobody wants to. I have the uttermost respect for our bug wranglers, wiki, forums and other staff. Also, you didn't include in this our testers.
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).
You forgot to mention that [core] has mandatory testing, even if, it's not enforced by the tooling.
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).
You're not account here for the bus factor. There's a reason why everyone can touch everyone's else packages. We're a volunteer based distro. Sometimes people can't handle stuff, but are still interested on the project.
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".
I think you're putting this they vs us mentality here. A lot of devs are also TU's, don't forget that. We also are usually the ones that bridge this allegedly "lack" of transparency.
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'.
I agree with this, and, even if we have the kanboard as Eli has pointed, we still lack more general guidelines. This could be on the page I mentioned above. Having said that, the fact we're a rolling release, has some limitations on this. Overall, I don't think we need a major revamp of the organizational structure, as it is now. Change for the sake of change is not necessarily a good thing. Regards, Giancarlo Razzolini
participants (7)
-
Allan McRae
-
Christian Rebischke
-
Eli Schwartz
-
Gaetan Bisson
-
Giancarlo Razzolini
-
Lukas Fleischer
-
Sébastien Luttringer