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
pgpEUc6sR7OoV.pgp
Description: PGP signature
