[META] Maintainership organisation

[elinorbgr]

So, at least for me the status who is responsible for what on the repo has been a little unclear. @tomaka has for all intents of purposes stopped maintaining winit. @francesca64 seems to have taken over the maintainership (though I don't know the details of how it happened), and have done an incredible work doing so, but the project is also clearly too active and too much of an energy drain to be handled by a single person.

We are a few to have commit right on winit, and yet @francesca64 seems to have to handle everything. I will not blame anybody, we all have our reasons. Mine are that given the lack of organization between collaborators with commit access, I'm not sure where to put myself in all that, nor how legitimate I am to merge pull requests. So, I feel we (or at least I) need to clarify how we share the roles between collaborators. I don't know who has commit right, and among those who are, who is willing to invest time in winit's maintenance.

Going to the heart of the subject:

@francesca64 what do you think of the current situation? Do you want to continue having most of the calls on the repo, or do you want to share the work, power, and responsibility?

Assuming you want to share, how do we organize it? I feel there are two main points:

• winit is pretty clearly separated into several backends, and it would probably be appropriate to clearly designate somebody as "the main maintainer" of each. For example, I think I am pretty clearly the maintainer of the wayland backend.
• general handling of the repo (closing issues, reviewing PRs, ...), and in particular a policy for merging PRs. I'd suggest something like "all collaborators can merge PRs as long as they have been approved (using the github UI) by at least two collaborators, including the maintainer of the impacted backend if relevant".

The main goal of this thread is to start a discussion. I don't have a strong opinion, but I feel the current situation could be improved and that we have been pretty bad at discussing all that before.

[tomaka]

One of my objectives when I started winit (and which failed) was to have a clearly-defined and minimal set of features after which nothing new would be added. Or that if something was to be added, the creator of the code would take the responsibility of maintaining it.

I'd really suggest pushing in that direction as well, in order to reduce the flow of issues and pull requests. After everything is implemented, this repo can be switched to "maintenance/bugfixing mode".

general handling of the repo (closing issues, reviewing PRs, ...), and in particular a policy for merging PRs. I'd suggest something like "all collaborators can merge PRs as long as they have been approved (using the github UI) by at least two collaborators, including the maintainer of the impacted backend if relevant".

For what it's worth, this can be enforced by github.

[mitchmindtree]

have a clearly-defined and minimal set of features

This does sound like the most realistic way of keeping the maintainership managable, at least until winit and @francesca64 get more support via more committed maintainers or maybe funding of some sort.

Perhaps it could be worth reviewing the #252 table, settling on a 1st class set of these features (perhaps what's already there?) and then punting maintainership of the other features and platform-specific extensions to their creators, at least until winit picks up more support?

as long as they have been approved (using the github UI) by at least two collaborators, including the maintainer of the impacted backend if relevant.

Yeah this would help to add a lot of confidence in merging PRs! I guess it would be up to @tomaka to activate this for the repo, provided @francesca64 agrees this would be for the best?

FWIW I'm quite invested in winit via nannou though I've been busy with some other work for the past two months. It looks like I'll be spending a lot of time on nannou again soon and into the new year and thus expect to be able to help with reviewing and testing winit PRs more often again. I currently have easy access to X11 and Wayland - ultimately I'd like to setup a way for testing windows and macos too (preferably some online service) but don't have a nice solution yet, any recommendations? Edit: I just got my windows 10 VM fired up again and successfully running winit examples.

Perhaps we can make the folks with merge access and their ability/willingness to review/test for each platform a little more visible with a table on the README? Having a table like this might help to give an idea of who can be pinged for review requests and advice. E.g. I'm picturing something along these lines:

Contributors	Windows	MacOS	Linux - X11	Linux - Wayland	Android	iOS	Emscriptem
@francesca64 patreon	✔️	✔️	✔️	✔️
@tomaka patreon	✔️
@vberger			✔️	✔️
@mitchmindtree	✔️		✔️	✔️

This is just an example and is incomplete/incorrect. I'd be happy to do a PR for this, though I'm not sure who else has merge access at the moment? Perhaps we could ping the others if there are any?

[elinorbgr]

Perhaps it could be worth reviewing the #252 table, settling on a 1st class set of these features (perhaps what's already there?) and then punting maintainership of the other features and platform-specific extensions to their creators, at least until winit picks up more support?

Fully agreed on that 👍

Perhaps we can make the folks with merge access and their ability/willingness to review/test for each platform a little more visible with a table on the README?

Or maybe in a CONTRIBUTING.md, with some more information regarding the scope of winit, and some general guidelines for contributors. To go into details regading your table suggestion that I quite like, do you think it'd be worth splitting the notion of "can test this platform / is main maintainer for this platform"?

For example, I can test winit on x11, and thus can probably review simple bugfix PRs for it, but my knowledge of x11 is very limited, and I'd absolutely not be capable of reviewing a large refactor or a significant new feature for example.

[sodiumjoe]

splitting the notion of "can test this platform / is main maintainer for this platform"?

I really like this idea, as I would be happy to test things on macos, but am similarly not equipped to do any serious code reviews.

[francesca64]

I've been quite busy with job hunting lately, and seeing how many notifications have piled up really affirms that this is a very important discussion to have. During the Summer, I had the time (and energy) to work on winit basically full-time, but even then, it was often hard to keep up on everything.

@vberger

and have done an incredible work doing so

Thanks so much!

what do you think of the current situation? Do you want to continue having most of the calls on the repo, or do you want to share the work, power, and responsibility?

Having too much depending on me is a bad idea, since unless I somehow get funding to work on winit, I can't guarantee I'll be here forever. Dividing up the work more would make things waaaaaay less stressful for me, too.

"all collaborators can merge PRs as long as they have been approved (using the github UI) by at least two collaborators, including the maintainer of the impacted backend if relevant"

This sounds like a good policy, so long as the small number of available collaborators doesn't become an issue.

@mitchmindtree

and thus expect to be able to help with reviewing and testing winit PRs more often again

Welcome back!

settling on a 1st class set of these features (perhaps what's already there?) and then punting maintainership of the other features and platform-specific extensions to their creators

I like this idea. People often seem to expect winit to be a kitchen sink of platform glue, so having a well-defined scope would help keep things sane.

Perhaps we can make the folks with merge access and their ability/willingness to review/test for each platform a little more visible with a table on the README? Having a table like this might help to give an idea of who can be pinged for review requests and advice.

I love this idea.

though I'm not sure who else has merge access at the moment?

@Ralith is the only other person I can think of off the top of my head, though they haven't been active. I don't recall seeing any other collaborators.

@Osspial doesn't have merge access, but is the person most actively invested in the Windows backend.

@vberger

a CONTRIBUTING.md, with some more information regarding the scope of winit, and some general guidelines for contributors

This would also be very good to have, especially since winit is likely more daunting than most projects for new contributors.

do you think it'd be worth splitting the notion of "can test this platform / is main maintainer for this platform"?

I think making that distinction would be very valuable, and it would scale well to when we hopefully have more people to ping for testing.

[elinorbgr]

Glad to see we are all on the same page regarding this. 👍

I'm going to prepare a PR with a draft for a CONTRIBUTING.md formalizing the suggestions. I believe having a document to discuss on and iterate will help deciding what to settle on, RFC-style.

[elinorbgr]

Opened as #674

[Osspial]

I would be happy to take up responsibility as the maintainer for the Windows backend, if that's an option that's on the table.

As far as platform testing goes I have access to X11, Wayland, and probably MacOS, though I wouldn't be able to contribute much to their development.

[Osspial]

@tomaka Would it be possible for me to get Collaborator status, so I can manage Windows issues and PRs?

[mtak-]

@tomaka If possible, could I also be granted Collaborator status for iOS issues/PRs?

[Osspial]

@tomaka ping

[Osspial]

Closing in favor of #830. It doesn't look like a whole lot more discussion is happening here, and that issue was partially intended as a continuation of this.