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

[Christian Rebischke]

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