We have no candidate for maintainer beyond 2018
jlfwong opened this issue · 9 comments
Just as we needed a maintainer when @divad12, @jswu, @mduan and I graduated, we will need a maintainer once @JGulbronson graduates in 2018. That seems a long way away, but our recruiting pipeline is dry!
Here's, very roughly, the pipeline we need to get people through before they could reasonably be a maintainer:
- Finds uwflow.com
- Finds UWFlow/rmc on GitHub
- Sets up Flow running locally
- Finds a small issue on GitHub they can work on
- Submits their first pull request and gets it merged
- Takes on a major feature and gets it merged
- Is vetted for trustworthiness by current maintainers and is given deploy keys
Given what we've done in the past, it's a small miracle we managed to find a new maintainer at all. Let's not rely on a second miracle.
Step 1) in our funnel is very healthy, so let's focus on 2) and 3) until we've got some serious movement there.
From talking to @JGulbronson in person, I think the following is a reasonable short term plan:
First, we should make sure it is dead easy to get set up locally. The current set up is painful when dependency installations fail, and the initial data sync is really slow. The first problem is fixable with some additional documentation now that Jeff has very helpfully gotten the repository running in docker. The second problem should be fixable by parallelizing the downloads and/or making them resumable on failure.
Once we have dead easy setup instructions, we should close the link between 1) and 2) by advertising on the site more aggressively that flow is open source. In particular, we should push this message really hard to students in Math or Engineering. This could be a sizable (dismissable) banner on their profile page.
So potential action items:
- Update the README to suggest Docker as the installation mechanism (this also unblocks developers who work on Windows!) along with instructions on how to get up and running locally with docker
- Draft a banner with logic to display it to students in Math or Engineering to prompt them to contribute to Flow
- Investigate how the initial data sync can be made faster
Awesome, thanks much for kicking off this discussion!
I'm wondering about a few things:
- What do we need in a maintainer? How much time is this currently taking Jeff?
- What major features do we have that we want folks to tackle?
Basically, I'm wondering if it's necessary to go through the same flow (no pun intended) that Jeff went to be maintainer — could it be possible that by fully understanding exactly what we want/need, we could solve this maintenance problem in other ways?
That said, I think the action items you've laid out are a great starting point, and I'd love to see folks get started on that!
Thanks for kicking off the discussions!
Agreed with David about 1) for all the reasons he listed.
I really like the funnel you laid out. I think that's a great model for thinking about this. You probably already had this in mind, but we should add tracking for the Github link (if we don't already) to get concrete numbers on the funnel.
@JGulbronson could you chime in more on 1)? How much time you spend, what kind of stuff you find yourself doing, what do you think would be most impactful, etc. I think I have some sense of what you've been up to, but there could stuff lots of stuff behind the scenes that I missed!
In terms of time for purely maintaining, it's not much. But ideally, the maintainer has others contributing, and encourages/helps them get set up and putting up PR's. So I think the first step is getting the funnel healthy like Jamie said, and getting regular contributions. I'll still be around for a while, so that should give us enough time.
To get people interested, the setup process needs to be as easy as possible. I have a Docker image that's usable, (and I see Jamie has a PR to fix it :P), so the next part should be parallelizing getting the data. Ideally, the amount of time from someone saying "I want to contribute!", to being up and running with data locally, should be as short as possible. Allowing them to get data faster would go a long way.
Great!! Get people interested and contributing and involved. :)
On Sat, Jun 18, 2016 at 5:53 PM, Jeff Gulbronson notifications@github.com
wrote:
In terms of time for purely maintaining, it's not much. But ideally, the
maintainer has others contributing, and encourages/helps them get set up
and putting up PR's. So I think the first step is getting the funnel
healthy like Jamie said, and getting regular contributions. I'll still be
around for a while, so that should give us enough time.To get people interested, the setup process needs to be as easy as
possible. I have a Docker image that's usable, (and I see Jamie has a PR to
fix it :P), so the next part should be parallelizing getting the data.
Ideally, the amount of time from someone saying "I want to contribute!", to
being up and running with data locally, should be as short as possible.
Allowing them to get data faster would go a long way.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#280 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAJvxzoNSnd4vW2bawXbQOSu_QkQWhwCks5qNJMYgaJpZM4IzTjh
.
I'll see if I can take some time this week to see what the setup process looks like and decrease pain doing it. It's not clear to me how to use docker to run locally at the moment.
Thanks Jamie!
On Sun, Jun 19, 2016 at 11:48 AM, Jamie Wong notifications@github.com
wrote:
I'll see if I can take some time this week to see what the setup process
looks like and decrease pain doing it. It's not clear to me how to use
docker to run locally at the moment.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#280 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAJvxxrsWmpsX1qR2uhJaDccJZyV5vcuks5qNY74gaJpZM4IzTjh
.
Closing in favor of #313