dlang-community as proper organization?

[WebFreak001]

It's unclear who is responsible for what in dlang-community, what are our working groups, who works on which projects, who makes releases, who decides what, etc.

Maybe if dlang-community wants to push forward contributions and form work groups we should have some organizational charts or governance documents to make clear who works on what and who to talk to.

Maybe we could have documents for contributors and define processes like eclipse does.

See https://www.eclipse.org/projects/dev_process/ especially

You can see all the discussions on here have gone stale after 2018, it's unclear who should reply to them and who decides about what gets in or what gets done.

I think if we have some basic structure we could for example better assign people to issues/PRs on projects and better define workflows how to work on stuff, define milestones, etc.

Ping @rikkimax @maxhaton @mdparker @PetarKirov @CyberShadow, would be interested what you all think

I think we would need someone in a leading position for the whole organization as well.

[rikkimax]

As an organization, dlang-community is setup as a backup should the code owner(s) not be around to do maintenance or develop further. It also gives a clear pathway for people to become a code owner (contribute).

In general, all the owners of the org should be interchangeable. We are only there to resolve situations where people want to contribute (but can't) and help them do so.

As for specific repositories... yeah that isn't clear which isn't a good thing.

[CyberShadow]

What kind of problems are you hoping to solve?

From what I see:

• We should make an effort to review incoming pull requests for all @dlang-community projects.
• If someone is trying to contribute but can't, we should help them (setting up GitHub integrations for CI etc.)
• If someone wants to work on something, we should let them. However, I don't think it makes sense to drop issues into someone's lap. It is entirely expected that projects in this org will continue to accumulate open issues, with probably nobody working on most of them, but this is an inevitable aspect of "project orphanage" organizations.
• If someone wants to take over ownership of a project (e.g. to steer it into a new direction), that should be discussed on a case by case basis.
• Privileges aren't important (except maybe to lessen security risks by applying principles of least privilege).
• Everything else isn't important.