Winit: 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 #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: https://github.com/tomaka/glutin/issues/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.

[vberger]

• 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. :sweat_smile:

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. :man_shrugging:

• 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?

:+1:

[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: tomaka/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: https://github.com/tomaka/glutin/issues/1114#issuecomment-471247726

[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!

[tomaka]

For what it's worth, I'm not really a fan of creating teams of people depending on their platform. This feels a bit too bureaucratic. But if you think it's the right approach, then whatever works!

[vberger]

For what it's worth, I'm not really a fan of creating teams of people depending on their platform. This feels a bit too bureaucratic. But if you think it's the right approach, then whatever works!

I'm not familiar with github teams, but it appears there are some communication facilities for teams? I guess this may be useful from a purely practical perspective.

[Osspial]

The main reason teams intrigued me was that they seem to add an easy way to ping everybody that can work on a given backend, but unfortunately there doesn't seem to be any way to make them visible to non-members (which seems weird, but I didn't see any options!). Listing the project's organization in a non-public place is a no-go for me, so I'm not inclined to keep looking at them for now, but they're something to consider revisiting if a more ad-hoc organization method ends up not working in the long run.

[tomaka]

You can only give ownership of a crate on crates.io to a specific team in an organization, so I've created a "Publishers" team with the intent of giving the rights to publish.
However due to this issue I can't do it unless I'm an admin of rust-windowing.

[Osspial]

Alright, I've given you owner privileges in the organization. You should be good to go now.

[vberger]

Will the travis build need some reconfiguration following the ownership change, to continue auto-publishing new releases?

[tomaka]

Normally no.

[goddessfreya]

How do I add these five crates to rust-windowing?
https://crates.io/crates/glutin_egl_sys
https://crates.io/crates/glutin_gles2_sys
https://crates.io/crates/glutin_glx_sys
https://crates.io/crates/glutin_wgl_sys
https://crates.io/crates/glutin_emscripten_sys

[tomaka]

@ZeGentzy cargo owner --add github:rust-windowing:publishers -- glutin_egl_sys (and similar for the others)

[goddessfreya]

"error: failed to invite owners to crate glutin_egl_sys: api errors (status 200 OK): only members of a team can add it as an owner"

[tomaka]

You probably have to make yourself member of "Publishers".

[vberger]

Do we have anything still blocking the actual launch of the marketing push?

[Osspial]

I don't believe so! I just need to write a short summary of what sort of help we want - I'll write that up and post a draft here tonight.

Sorry about the delay - I haven't had a whole lot of free time in the past week or so. That's been somewhat my fault though, and I've been working on rebalancing my schedule to give myself more time for hobbyist work, so I should have more time going forward!

[Osspial]

Triaging pass done! I've compiled a list of the issues we can ask people for help on here. That's missing some links and has some WIP comments, but it should be a good start.

I was meaning to write the actual help request after getting that list together, but going through all the issues took way longer than I expected and I honestly don't have the energy to do more writing right now. I'll definitely pull it together tomorrow, though.

[Osspial]

Not particularly timely, but I've got a first draft: https://gist.github.com/Osspial/1a93d599189f49a97884c4aa033e9ef3

I'm not entirely happy with that, for various reasons (off the top of my head, though there are undoubtedly more):

• The main body doesn't talk much about the state of mobile
• The transition to the call to action feels weak

I'll work on that more later, but in the meantime any additional feedback is much appreciated.

[xStrom]

Minor typo:

_heard of ode_

[goddessfreya]

@Osspial Can we add the following to the list of tasks:

Windows:
(glutin) Support statically-linked libEGL? (On Windows) https://github.com/rust-windowing/glutin/issues/997
(glutin) Improve headless backends. https://github.com/rust-windowing/glutin/issues/1106
(glutin) Investigate headless context falls back to GL ES on AMD https://github.com/rust-windowing/glutin/issues/583
(glutin) Implement raw context extension for this platform. https://github.com/rust-windowing/glutin/issues/501

Linux X11:
Implement XCB support
(glutin) Add ability to choice between EGL and GLX on linux, without changing the opengl version. https://github.com/rust-windowing/glutin/issues/1140
(glutin) Improve headless backends. https://github.com/rust-windowing/glutin/issues/1106
(glutin) Investigate why setting robustness with EGL fails https://github.com/rust-windowing/glutin/issues/892

Linux Wayland:
(glutin) Investigate why setting robustness with EGL fails https://github.com/rust-windowing/glutin/issues/892

iOS:
(glutin) Implement context sharing. https://github.com/rust-windowing/glutin/issues/899
(glutin) Implement raw context extension for this platform. https://github.com/rust-windowing/glutin/issues/501

Android:
(glutin) Implement context sharing. https://github.com/rust-windowing/glutin/issues/899
(glutin) Implement raw context extension for this platform. https://github.com/rust-windowing/glutin/issues/501

Macos:
(glutin) Detect errors on calls to *MakeCurrent https://github.com/rust-windowing/glutin/issues/84
(glutin) Implement raw context extension for this platform. https://github.com/rust-windowing/glutin/issues/501

Emscripten:
(glutin) Detect errors on calls to *MakeCurrent https://github.com/rust-windowing/glutin/issues/84
(glutin) Implement raw context extension for this platform. https://github.com/rust-windowing/glutin/issues/501

Meta:
(glutin) Handle window resizing in examples. https://github.com/rust-windowing/glutin/issues/1068
(glutin) Change vsync from bool to Option https://github.com/rust-windowing/glutin/issues/631
(glutin) Cleanup properly when code fails. https://github.com/rust-windowing/glutin/issues/10
(glutin) Handle flush control. https://github.com/rust-windowing/glutin/issues/507

EDIT: And of course, the things on my milestone list: https://github.com/rust-windowing/glutin/milestone/2

[goddessfreya]

Linux X11:
(glutin) Raw context support w/ transparency https://github.com/rust-windowing/winit/issues/832#issuecomment-487351173

[goddessfreya]

Updated: https://gist.github.com/ZeGentzy/38f29bc1b4c2bddfaab4817a1b34a67d @Osspial

[goddessfreya]

Since triaging is such a calming task, I've went through and marked issues that I think are good first issues as such.

[Osspial]

Hey, quick update on where I stand on this, since the actual help wanted post is ready to go: I'd like to get the eventloop-2.0 branch onto master before we send this out, to avoid getting PRs against legacy code. That involves addressing #837 and #886, but we've got pretty clear directions to go on both of them so that shouldn't take too too long.

[felixrabe]

I'm trying to finish up a prototype application (been working on it for weeks already) using the legacy event loop, with the intent of immediately porting it over to the new event loop once I get it working. Then (hopefully soon) I should be able to provide some feedback on eventloop-2.0 on macOS 10.13.

[Osspial]

At this point I'm tempted to just leave #895 where it is and release regardless, since it seems pretty unlikely that it'll get merged before we have someone that can handle macOS.

[aloucks]

and release

Does this mean merge eventloop-2.0 to master (and publish to crates.io)?

I think the X11 backend needs some work. My simple examples were suffering from lost events.

See also #865

[vberger]

I'd suggest merging the eventloop-2.0 branch (or replacing master with it and moving master into a winit-1 branch or something like that, to avoid a complicated merge), and release a 0.20.0-alpha1 version of winit based on that.

This way we can release a version that people can easily depend on for battle testing and bugfixes and start attempting to port their applications, while it remains clear that the new winit is not yet polished. It can then serve as a stepping stone for the marketing push ("help us find the remaining bugs and fix them !").

What do you think?

[Osspial]

@vberger That sounds great! I can handle doing the branch juggling (and maybe deleting most of the old, unused branches still in this repo) tonight.

[Osspial]

Branch juggling has been completed, and PRs have been updated to be against their proper branches.

[vbogaevsky]

I'm glad to join winit team as a macOS maintainer!