search

purescript / governance

22 stars 2 forks source link

Expanding on roles and decision making #3

Closed hdgarrood closed 4 years ago

hdgarrood commented 4 years ago

See also #1. This PR mostly aims to document what the current roles and processes for decision making and getting things merged are, so that they will be clearer to the wider community. That is, most of what I have written here is intended to describe the current model (rather than prescribe a new model).

Unlike in #1, I haven't described a "Language Supporter" role: in order to keep this PR small, I would prefer to focus just on people who have commit access to the compiler and/or core libraries for now.

There is also a part of this PR which does (sort of) represent a change in the governance model, however. I would also like to start giving commit access (i.e. "core collaborator" status) to some people on the compiler repository. Up until now, we haven't done this at all; everyone who has commit access on the compiler repository is currently a "core owner".

I would like to add more core collaborators because we are a little overstretched: we are not recruiting new maintainers at a very high rate, and I think there is a bit too much going on for us (i.e. the current core team) to be able to comfortably keep up with right now.

I think the main barrier to offering more people commit access on the compiler repo right now is that it is not entirely clear what would be expected of them. With the changes in this PR, I hope to make expectations clear, so that we can start adding people as core collaborators for the compiler repository, and so that these people will feel empowered to help out without worrying about overstepping expectations.

Finally, there are also some changes to make the formatting of this document more consistent, and some minor clarifications (e.g. in the Purpose section).

hdgarrood commented 4 years ago

I should add that my views on this topic have been shaped a lot by discussions such as https://discourse.purescript.org/t/rfc-documenting-purescripts-governance-structures-policies-processes/1110/ and I would like to thank to the people who were involved for helping me to realise that we do have a project health issue and for suggesting how we can address it, particularly @f-f and @joneshf.

hdgarrood commented 4 years ago

Do people mind if I merge this now and create new issues for the unresolved questions? As far as I can tell, those are:

Is that everything?

hdgarrood commented 4 years ago

There are definitely cases where things can be merged immediately, though. This would essentially say that all PRs should wait at least 3 days before merging, right? I'm pretty confident that's not what we want. For instance, just from the last couple of weeks, there was https://github.com/purescript/purescript/pull/3856, https://github.com/purescript/purescript/pull/3853, https://github.com/purescript/purescript/pull/3850, all of which were merged in what I think was an appropriate amount of time.

f-f commented 4 years ago

@hdgarrood the original intent about specifying a "timeout" in my review was to put an upper bound, not a lower bound. I.e. I would like to see a "time limit after which something is automatically approved if not enough voters chime in" - which is to avoid things being stuck. I'd say it's important to specify something here (even if it's maybe too long, like "1 month"), so that future contributions are subject to this process and timeout. I agree with you that I don't see the need for a lower bound right away, since small things do not need to wait for much. (though I'd still say we could open an issue to have a discussion there)

joneshf commented 4 years ago

Sorry, I misunderstood what the situation was and wrote minimum. I'm not trying to start a different discussion, just messed up.

I'd say it's important to specify something here (even if it's maybe too long, like "1 month"), so that future contributions are subject to this process and timeout.

Agreed. This is the only thing I'm concerned about. I only made a suggestion so it wasn't just me blocking the merge without trying to move the merge forward. I'd be satisfied with any specific time as long as it's written down.

hdgarrood commented 4 years ago

Ok then, I'm happy to say that if something was approved by one or more core owners a month ago and no other core owners have objections, then we can always consider it approved (although we will not expect it to take that long in most cases).

hdgarrood commented 4 years ago

Ok, I just pushed a new commit. How's this?