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

[Giancarlo Razzolini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 870 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20190602/aed15f8c/attachment.sig>