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

[Eli Schwartz]

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/964f9d8069094e955512b8edf75d2bb48c96a074983f7fd5e9550ac35094

Anyone who wants access to this board should please contact the devops
team for a kanboard account.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1597 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20190601/34977330/attachment.sig>