Preparation for contributor marketing push

[Osspial]

Winit needs more people actively working to improve it; the current crop of maintainers has been doing great work, but due to the nature of volunteer work said efforts aren't guaranteed and we don't have any contingency plans in the event that a platform maintainer stops being able to work on their platform. That is unacceptable, given Winit's foundational place in the Rust windowing, GUI, and gamedev ecosystems. I'd like to start a broader marketing push to get more people working on each of the backends (which I'm happy to helm), but there are a few questions I'd like to get resolved before getting started on that:

1. Should a single person be allowed to maintain more than one platform?
2. What is the maintainership status of the @francesca64's (macOS, X11, and Android) platforms?
3. Should we implement an automated mechanism for assigning contributors to bugs?
4. In CONTRIBUTING.md, how should we list individuals that are able to contribute code to a platform, but don't necessarily have the time to maintain it? We don't have a role listed explicitly for doing that.
5. Should we move Winit and related projects into a new GitHub organization?

I've got personal stances on most of those issues, but I'm going to reserve those for a separate comment so to keep the starting post relatively unbiased.

cc @tomaka @francesca64 @mitchmindtree @vberger @mtak- @zegentzy @ryanisaacg

[Osspial]

My stances:

1. I'd say no. Doing so creates a massive single point of failure upon which on the entire Winit project can stall, which we've run into trying to get the EventLoop-2.0 changes out the door. Reducing the amount of work somebody is responsible for makes it easier to replace them if they can't do their work.
2. @francesca64 has been MIA for several months, and from private conversations with her it doesn't sound like she has the time to contribute to Winit. I'd like to market all of these platforms as needing new maintainers given the extended inactivity on them, but I haven't gotten her explicit permission to do that and I don't like the idea of forcibly unlisting somebody from work they volunteered to do.
3. The current bug-fixing system is incredibly ad-hoc - when a bug for a given platform gets reported, we rely on somebody stepping up to find a solution. With the current number of active contributors, this isn't sustainable: oftentimes, it takes several weeks for the maintainer to find the time to investigate a platform's bugs, and there are some bugs in the backlog that have been sitting untouched for many months. Given that, I feel like adding an automated bug-assignment system is essential, but doing that requires having a greater network of people to which we can assign bugs.
4. I'd like to rename Reviewer to Collaborator, as Collaborator implies that you're more able to actively contribute. That also helps build up a network for the bug-assignment system brought up in PRs that need to be merged into winit #3.
5. Yes. I think this is necessary for improving our Android support, given the current state of android-glue - it's essential for the Android backend, but entirely unsupported. That will enable us to more efficiently add new maintainers and manage PRs for related projects (such as android-glue), without having to wait on @tomaka to approve any organizational changes we make.

[goddessfreya]

A marketing push would be wonderful. Hopefully that'll get evlp-v2 out the door and more people working on winit/glutin. (I'd be really happy if we had more people working the non-linux platforms for glutin, as I feel they're being left to suffer to bit rot)

• Should we implement an automated mechanism for assigning contributors to bugs?

I don't think an automated mechanism would solve this issue of bugs sitting inactive for forever. We don't have that many people, and no one (at least I don't) wants to go too far back in the pile of bug reports, because that requires trying to figure out if bugs are still relevant.

For example let's take #391 (chosen randomly, cause I liked it's name). It's related to #1033, whose latest comment says #1033 is no-longer reproducible, and #574, which was fixed. Is #391 still reproducible? Maybe, I don't have a windows rig to test if it still is, and given there is an other ~100 old issues like it, I don't think anyone's going to be testing it any time soon.

Just going through the issues someday and checking if they're still relevant would probably shutdown ~20%
of them without even having to build or test anything. I read through 80 issues in one day for glutin, and closed 12 of them without having to build a single thing, because they were either duplicates or completely irrelevant. See here

Second: can we be at least tagging issues by platform? Only 10 of the 25 issues on the first page have any tags at all. It would be nice to be able to sort by platform :)

I'd be willing to do both task, if required.

• Should we move Winit and related projects into a new GitHub organization?

Yes please. Glutin now uses this hack for android-glue to hold android together just enough so that its CI it still builds.

EDIT: Can will we add glutin to this organization? I hope so.
EDIT: rust-windowing/glutin#898 Maybe we can hijack the glium organization, and give it a different name.

• In CONTRIBUTING.md, how should we list individuals that are able to contribute code to a platform, but don't necessarily have the time to maintain it? We don't have a role listed explicitly for doing that.

Isn't that Reviewers? Don't care how it's named, personally.

• Should a single person be allowed to maintain more than one platform?

I don't see why not. A massive single point of failure might be a concern, however, I think we can combat this by striving for 2, or more, maintainers per platform. That way, if someone goes MIA, we still have some else.

• What is the maintainership status of the @francesca64's (macOS, X11, and Android) platforms?

I think it should be okay to delist her, after getting her permission. Till then, no harm having a second maintainer for those platforms.

[elinorbgr]

• Should a single person be allowed to maintain more than one platform?

I'd take this question on the over way. I don't see any fundamental issue with one person being maintainer of more than one platform, but I think it'd be better to have more than one maintainer per platform.

As a personal example, I think it is quite obvious that the set of people programming in Rust and very familiar with Wayland is, well, pretty small. A few years ago I accidentally became a maintainer of winit, because I contributed a Wayland backend to it while my primary intention was to use this backend to battle-test my Wayland bindings. 😅

Still I see that winit and Wayland-related support to downstream crates takes up a large portion of my open-source time, and I really would prefer to share that burden. As I've said several times, I'd be quite happy to mentor anyone interested with how Wayland works, but it looks like not many persons are interested by it at all. 🤷‍♂️

• What is the maintainership status of the @francesca64's (macOS, X11, and Android) platforms?

As said previously, I believe we need more than one point of contact per platform anyway. And I guess if she does not have any more time to devote to winit, it may make sense to only display her as Contributor/Reviewer (whatever we call it) so that people don't try to contact her first. But I'd not change her status without her approval.

• Should we implement an automated mechanism for assigning contributors to bugs?

Do you mean something similar to what the rust repo does? A bot that automatically assigns issues to a random contributor, which is then responsible for tagging the issue appropriately and reassigning it to a more relevant person if necessary?

If so, why not, but that would only make sense once we have a large enough number of contributors in my opinion.

• In CONTRIBUTING.md, how should we list individuals that are able to contribute code to a platform, but don't necessarily have the time to maintain it? We don't have a role listed explicitly for doing that.

I don't have a strong opinion wrt to that.

• Should we move Winit and related projects into a new GitHub organization?

👍

[Osspial]

I don't think an automated mechanism would solve this issue of bugs sitting inactive for forever. We don't have that many people, and no one (at least I don't) wants to go too far back in the pile of bug reports, because that requires trying to figure out if bugs are still relevant.

Do you mean something similar to what the rust repo does? A bot that automatically assigns issues to a random contributor, which is then responsible for tagging the issue appropriately and reassigning it to a more relevant person if necessary?

If so, why not, but that would only make sense once we have a large enough number of contributors in my opinion.

re:ZeGentzy & vberger - I'd agree that this is a later-stage action to take, once we've built up enough contributors that all issues aren't randomly assigned to a single person. Also, we probably should only do it for new issues, than manually triage old issues (which we desperately need to do!).

re:vberger - yeah, that's roughly what I mean. When we do it, I'd also like to set up a system to allow issue submitters to automatically tag a particular platform so that issues get randomly assigned to a contributor to that platform.

Isn't that Reviewers? Don't care how it's named, personally.

I don't have a strong opinion wrt to that.

My gut feeling is that how the position is named changes how people behave - if it's just "Reviewer", that implies that the only responsibility is reviewing other peoples' PRs, while "Contributor" implies more actively tackling issues. It also more clearly communicates the intent of can be assigned to investigate platform-specific issues. I don't know how well that feeling translates to reality, though.

I think it should be okay to delist her, after getting her permission. Till then, no harm having a second maintainer for those platforms.

And I guess if she does not have any more time to devote to winit, it may make sense to only display her as Contributor/Reviewer (whatever we call it) so that people don't try to contact her first. But I'd not change her status without her approval.

That's my gut feeling too, but my concern is that keeping her listed as maintainer will result in bad experiences for new people contributing to those platforms - if she's listed as the maintainer, it makes sense for new contributors to ask her to review changes, but since she's unable to do so she won't. The solution is either downgrading her status from maintainer or delisting her, and I've asked her about doing that, but I haven't gotten a response in over a week. I don't want to wait forever for her to officially update her status if she isn't intending to do it.

Still I see that winit and Wayland-related support to downstream crates takes up a large portion of my open-source time, and I really would prefer to share that burden. As I've said several times, I'd be quite happy to mentor anyone interested with how Wayland works, but it looks like not many persons are interested by it at all. 🤷‍♂️

That's the hope of the marketing push :D! We haven't gotten a whole lot of people offering to help, but we also haven't been asking for it, and we have enough people using Winit (looking at the stats, we get almost 900 downloads per day!) that that'll likely change once we start more aggressive outreach.

EDIT: Can will we add glutin to this organization? I hope so.

Yeah, getting glutin under the new organization is the intent. I've created the rust-windowing organization for this purpose, and have started inviting people over to it, but we still need to get @tomaka to transfer over the GitHub and crates.io rights before we can really get it going.

EDIT: rust-windowing/glutin#898 Maybe we can hijack the glium organization, and give it a different name.

I feel there's enough difference between Winit/Glutin and Glium to put them under different organizations.

[Osspial]

@tomaka Could you transfer this repository, glutin, and android-glue over to rust-windowing?

EDIT: And give crates.io ownership rights to the members of those organizations?

[Osspial]

@tomaka ?

[goddessfreya]

@tomaka has been MIA for a long while: rust-windowing/glutin#1114 (comment)

[Osspial]

He's active on GitHub at least, so we know he's not dead. I'm assuming he's just muted these repositories, so I'll drop him an email and see if he responds there.

[felixrabe]

rust-windowing

Hah, that's exactly the name that I was thinking of when I started reading this issue :) .

A different suggestion regarding @francesca64: Keep her listed, but also explicitly state that she is "currently [ not active in / absent from ] this project as of April 2019 and might take a while to respond", or something like that, e.g. as a footnote.

[felixrabe]

About me:

I've been here a few months ago doing some experimental stuff, getting started with both Rust and graphics programming. I'm currently picking that up again with a focus on learning Vulkan (and maybe gfx-rs / wgpu). I don't want to promise anything, but should that path continue, I can see myself contributing to winit in some way (other than half-OT commenting on issues) in the future.

About outreach:

I'm regularly checking out https://this-week-in-rust.org/ – once this "contributor preparation" is finished, make sure to get listed there!

Also, I'm listening to various podcasts from around the ecosystem, such as https://newrustacean.com/ (still making progress). Someone who's been working on winit a few months might reach out to Chris for making an interview, especially as it seems he's working on a cross-platform GUI app himself: https://twitter.com/chriskrycho/status/1114696179042869249.

[felixrabe]

(Hoping to get to </rant> ASAP, but till then:)

Also potentially worth checking out related to this issue (I haven't listened to them, but seen their titles) are several podcasts of https://changelog.com/podcast on maintaining / sustaining / funding open source projects.

Edit: Alright, before I post anything more, I'll see about setting up these chat clients :) </rant>

[tomaka]

Sorry, I tend to ignore/disable notifications from GitHub because they pile up too quickly (I've got 70 notifications at the moment for example).

I'm definitely in favour of a move to a rust-windowing organization, and I'm glad that people are continuing glutin, winit, and the android crate. Since I haven't seen anyone opposed to this move in this discussion, I guess I'll do it!