Restructure and formalize the organization

[glennsl]

There's currently no formal document outlining the purpose and workings of the reasonml-community organization. As a result, it''s very unclear to both consumers and members what it means for a repository to be part of the organization, and many repositories are perhaps neglected even more than they would be if they were still associated with the original author(s).

To address this I propose a restructuring and formalization of the organization, with the first step being to have the current organization members vote on the following basic structure:

• Every repository should have a single responsible maintainer.
• Maintainers volunteer, and are accepted if at least three (3) existing members agree. If there's multiple volunteers, and they all insist on it, the person with most "votes" win.
• Post-restructuring, the organization will be made up of only the maintainers. Other members will be removed.
• I (@glennsl) will be authorized to coordinate, and to add and remove members during the restructuring.
• This proposal will be considered approved if an absolute majority of members have voted to agree. That is, if at least 11 of the current members (listed below) have given this issue a thumbs up (edit: or a heart or comment, since I can only see the first ten people on each emote). Other kinds of thumbs, by non-members or of the downward kind, will be noted but otherwise gleefully ignored.

Once the restructuring has been completed, the new organization will be able to decide on the details by using the issues on this repository to discuss and vote on them. Decisions should ideally be reached via consensus, but if all else fails an absolute majority of members decide (This can of course be re-decided on later, as can everything else).

cc @bassjacob @bobzhang @bsansouci @chenglou @cristianoc @emmenko @glennsl @IwanKaramazow @jaredly @jimexist @jordwalke @jsdf @mransan @ncthbrt @rickyvetter @rrdelaney @saschatimme @vramana @yawaramin @yunxing

[jimexist]

I've got questions regarding other new projects and their ownership, etc. but I guess that can wait until the result of this comes through.

[glennsl]

I've been working on a much bigger proposal that I think covers that and plenty of other questions you might have. This all needs to be decided on later, of course, but if you're curious what my thoughts are, it's here: https://github.com/glennsl/reasonml-community-meta-proposal

[rrdelaney]

Is there a need for something like this? I don't see why we can't have a README that says something like "trusted community packages, if you'd like to get yours here contact ".

I don't think having general structure and guidelines for each repo is bad, but I also don't see why each repo needs exactly one maintainer.

[glennsl]

I'm actually not proposing there should be only one maintainer, just that there should be only one responsible maintainer. I see no reason to have a limit on the number of collaborators/maintainers, but not having a single point of responsibility leads to diffusion of responsibility, which seems to me to be apparent on most of the repositories currently.

Also, as far as this proposal is concerned, it's only intended as a starting point, to provide some basic structure and a proper mandate to build the organization on. We can decide on something else later.

My view on decisions like this is that they just need to be good enough, not perfect. Just so that we're able to move forward without getting stuck in endless discussion. Making a decision doesn't necessarily mean the discussion has to stop (sometimes that's nice too though, but then it should be made clear).

[yawaramin]

Great ideas Glenn. I would suggest one modification: each repository in the community should be scoped under its primary responsible maintainer and uploaded to npm under the reasonml-community scope iff it is accepted as a community-contributed package under the rules you proposed. Up until then (and also afterwards) it may well be uploaded under its original maintainer's scope.

The reasonml-community scope packages would simply be pointers to the existing maintainer-driven packages.

Would this be feasible?

[glennsl]

I'm not sure I understand what you mean. Are you talking about just npm scopes, or are you referring to the repository owner/org/user as a "scope" too?

Also, is this tied to the decision this issue is dedicated to, or can we create a new issue to discuss it and decide on it later?

[yawaramin]

Concretely, I mean:

• Maintainers own the repos, e.g. https://github.com/glennsl/reason-foo
• If a repo gets accepted as a community contrib:
  • it stays under the maintainer's GitHub as before
  • It gets uploaded to npm under the reasonml-community scope, e.g. @reasonml-community/reason-foo
• If a repo's maintainership changes hands:
  • The new maintainer's repo is uploaded to npm under the same scope as before, i.e. @reasonml-community/reason-foo

I feel that this structure would scale well.

[glennsl]

Right, I can see how that has some benefits, but I also see a major downside: Organization members would not automatically get access to the repository to be able to step in. So repository access would either have to be micro-managed for each repository, or we'd be moving away from community-managed repositories towards just community-organization. Which isn't necessarily bad, but certainly different from what I've had in mind at least :)

In any case, I suggest holding off on discussing this for a bit to avoid derailing this process and losing momentum before there's even an organization to make the decision, and instead create an issue for it after the restructuring.

[yawaramin]

Yup, agreed. Let's get the show on the road first :-)

[rrdelaney]

@glennsl Ok, looking over the original post looks fine to me.

I disagree with some stuff in your more detailed proposal, but can hash that out later.

[bsansouci]

@glennsl The basic structure looks good to me.

Thanks for bringing this up! This is great.

[emmenko]

This proposal sounds very reasonable to me, thanks for addressing this! 🙌

---

For the next steps we should probably talk a bit about conventions. As @yawaramin mentioned, the scoped packages is definitely one interesting topic. I would also imagine things like contributions guidelines, repository structure and so on, so that (at least) all repository within this organization conform to certain rules, instead of everyone doing different things.

But yeah, not really part of this discussion 😅

[glennsl]

Thanks!

I think you (or anyone else) could start writing a wiki page, and/or create an issue for discussing these topics right away. Guidelines shouldn't need a formal decision, I think. Unless it's decided to really enforce them of course. These are also topics where people outside the org likely want to follow and have lots of opinions about. Just be respectful and careful about insisting on controversial issues, then I think (hope!) free-form collaboration should work fine.

Just my two cents :)

[glennsl]

Alright! We've reached 11 votes, with no one having voiced disagreement with the basic structure decided on. If you haven't voted, please still do. The stronger the mandate the better.

I've created a new issue for electing maintainers in #2. Please go there to volunteer and approve maintainers.

Once we've decided on maintainers and completed the restructuring, we can start making decisions on other topics, but I see no reason to not start discussion now. If you have something you're burning to bring up, you can either make an issue here, or take it up in #bikeshedding on Discord, depending on the "formality" of it, I'd say.

[glennsl]

Phase 2: The Search for Maintainers and Phasse 3: The Great Purge, has now completed. I hereby declare the restructuring complete!

With an active and well-founded member base we can now begin to decide on the details. I'll open a new issue for discussion a specific topic shortly, but please don't hesitate to open issues for discussion if there's something you're burning to bring up.

[chenglou]

Thanks so much for having taken care of this without adding much administrative overhead =)