search

exercism / discussions

For discussing things like future features, roadmap, priorities, and other things that are not directly action-oriented (yet).
37 stars 5 forks source link

How do we ensure that tracks are not orphaned? #3

Closed kytrinyx closed 7 years ago

kytrinyx commented 8 years ago

At the moment there are some tracks that have active maintainers, and others where even a simple, obvious fix doesn't get merged.

It would be great to get an overview of which tracks currently have active maintainers and which tracks need someone to take them over, and then also figure out how to find new maintainers for tracks that are not getting attention these days.

Ideally a track should have at least two people who are currently actively involved. If a track only has one maintainer, we should find someone else to help out. If the track has several maintainers but only one person is actually currently doing any of the work (fixing things, reviewing and merging pull requests, responding to issues), then we should also consider finding people to help out.

We might also remove people from the maintainer teams if they've not been active for a long time (email them and let them know, in a way that makes it clear that it's not personal, and should they want to get actively involved again, they're more than welcome to).

So, action items, I think:

kytrinyx commented 8 years ago

Here's the list of active tracks, as of March 22nd, 2016. Checkmark indicates that the track is known to have active maintainers.

Will continuously update as I investigate.

ORPHANED

POSSIBLY AT RISK

abitdodgy commented 8 years ago

@kytrinyx I'm just tossing my name in that hat; I would be happy to contribute.

petertseng commented 8 years ago

Pretty sure I can vouch for Rust having two recently active maintainers, so you could check that box.

Under some other circumstances I might have suggested I take on Haskell, but not now, as I still need at least some weeks to understand my current work. In the interim, until finding an actual Haskell maintainer I suppose I can be on a "break glass in case of emergency" basis, maybe review some PRs that really need a reviewer, but not everything that comes with maintainership.

Finding maintainers is hard! Let me take an idea currently in use on other places on the site and expand it a bit to see if it can help. You know how the "About this language" page has a "Help us explain this better! File a GitHub issue at https://github.com/exercism/xLANGUAGE/issues"?

What if on the test suite page (e.g. http://exercism.io/exercises/ruby/leap) there were something that says "Help us improve these test cases! File a GitHub issue at..." ?

To help inform what kind of suggestions would be most helpful, let's ask which do we think is true:

How to see whether maintainers are still around is also tough. And we'd better not mistake "the maintainer is around but nobody has been submitting issues to the track so there's nothing to be done" for "the maintainer's not around anymore".

What would the ideal process for determining maintainer activity be? One extreme is that periodically one person looks through all the repos and makes some observation, but that's a lot of work to put on one person. Wouldn't it be good to load balance?

Or maybe all track maintainers should periodically fill out a short form whose question is "Hi, how's your track doing? Any issues lately?" (and to be clear it would be perfectly acceptable to just say "yup no issues") so that it is possible to see who hasn't responded to that for a while. But would track maintainers balk at having too much process, and is even that simple form too much? If instead of the survey it was just a "Hi I'm alive" every X weeks would that also be considered too much?

To me, something that would have definitely been too heavy-duty would have been some kind of monthly maintainers meeting. How would we have found a time that works for a good portion of the maintainers, and really what would the content of such a meeting be?

All brainstormy, and I'm not sure of my own answer yet, but maybe they will lead someone to find an idea that does stick.

kytrinyx commented 8 years ago

My guess is that for the most part it's the 3rd option; people are probably not aware of the fact that we'd welcome contributors and contributions.

How to see whether maintainers are still around is also tough.

Yeah, there are some language tracks where not changes.

Ideally I would want this to be incredibly light-weight–no meetings! I'm not yet sure how to do this. Perhaps the approach of asking how things are going (even just sending out an email) would work, as long as it's not too often.

I also want to find a way to make it absolutely clear that it's totally fine to say "I'm getting too busy with other things" or "I've lost interest and am moving on". I'm not going to get upset or take it personally, and I'd rather know so that we can approach someone else about taking on the track.

kytrinyx commented 8 years ago

@abitdodgy Thanks! Where/in what capacity would you be interested in contributing?

kotp commented 8 years ago

Is there a set of metrics that can be a 'trigger' for asking if someone would like to contribute via the exercism data? Those that participate in several tracks are likely skilled in at least one language area, and just about everyone can contribute to documentation, testing, and feedback.

The client itself can hold some language that indicates that "Contributors are welcome, see URL for more information." and I think it would be non-intrusive.

kytrinyx commented 8 years ago

Is there a set of metrics that can be a 'trigger' for asking if someone would like to contribute via the exercism data?

That is an excellent question. One thing would be people who comment a lot in a given language track. That might not mean that they feel confident about their skills in the language, but it would mean that they have an interest in the language beyond just writing code. Comments could be asking questions as much as providing feedback, but I find that both of these things are useful indicators.

Another metric we could look at would be contributions to the track itself.

The client itself can hold some language that indicates that "Contributors are welcome, see URL for more information." and I think it would be non-intrusive.

Yes, provided that it is not on submit/fetch. Perhaps as part of the "help" text.

kotp commented 8 years ago

Right on, yeah, unobtrusively on the client. (Yet the client is also the website itself... "Your enthusiasm on Exercism has gotten our attention, and we happen to be looking for contributors! Would you be interested? URL here") )

kytrinyx commented 8 years ago

Oh, yeah, good point. Something on the site itself would be great. We could stick that on the dashboard, maybe.

abitdodgy commented 8 years ago

@kytrinyx I can help wherever I'm needed and however I can. I'm decent at Ruby, so I would be happy to be a track maintainer. I'm also studying Elixir, and I've authored a library with it, but I need more time to be confident. I'm also studying Swift, but I'm still a beginner.

kytrinyx commented 8 years ago

I've been thinking about this over the past couple of days, and there are a few things that I noticed about how I've invited people to be contributors before. Almost always, it's been the case that someone has started contributing, and I've noticed that they've been being helpful--or one of the other maintainers has noticed it.

Over the past 3 years a LOT of people have offered to help out and then either not ever actually done anything after I help them get set up, or they'll maybe do one thing and then we never hear from them again. This is totally normal in open source, as far as I can tell, but it does mean that in order to trust someone with the keys to a repository, it usually takes a little bit of time and some regular involvement.

The best way to get involved is to watch the repositories that you're interested (so you get notifications about issues and pull requests) and then participate in the discussions in various ways:

I'm sure that there are things that I can do that would make it less intimidating for people to get involved. I know that @jtigger ended up getting involved in the Java track partly because we had conversations in meat-space, and he was able to ask a bunch of questions that it probably didn't feel comfortable to ask about in issues or pull requests. I'd like to figure out how to make it so that those types of questions are answered up front, and that people should be comfortable asking them (for example here in the discussions repository).

One of the developers I know got involved in the Rails project by helping out with triaging issues. http://words.steveklabnik.com/how-to-be-an-open-source-gardener It's really interesting, because it didn't take a lot of time before he was making a TON of commits, and he was eventually given commit on the Rails project itself.

I'm not saying that the way to become a track maintainer (or whatever) here on exercism should be via issue triage, but his story does reflect this idea that you show up and start doing stuff, and by doing that you end up getting more of a view into what's working and not, what's needed and not.

@abitdodgy I'm not writing this to you in particular (and I've emailed you separately), this is mostly thinking out loud about the whole process.

I'd love feedback on this--am I too pessimistic/optimistic/naive/something else? What can I do better on my end to help people feel like they're welcome to jump in and get involved?

kotp commented 8 years ago

I would love to meet the Ruby maintainers, actually. Hopefully people realize and know that I am available via gmail chat (e-mail address per the commits). And hopefully people know that they are free to chat me or mail me at the e-mail address in the commits.

petertseng commented 8 years ago

Almost always, it's been the case that someone has started contributing, and I've noticed that they've been being helpful--or one of the other maintainers has noticed it.

It makes sense that the most likely place to find people who would want to contribute in the future is... from those who have already contributed in the past.

I might take a moment to say that there may be some contributors who e.g. are happy to send in PRs but don't want the responsibility of reviewing others' PRs and/or fixing issues on the track. That said, I think this doesn't much affect the conclusions we should draw from this discussion, since the same has been true in the past as well.

I echo the already-expressed sentiment that something on the website would be good. I know that there's already a link on the main page (there's a Github link near the bottom) but it could probably be put in a more prominent location and made clear that you can "Contribute on Github" or "Get Involved!" or something that makes clear that ideas are welcome.

The best way to get involved is to watch the repositories that you're interested (so you get notifications about issues and pull requests) and then participate in the discussions in various ways:

I think such a list should go somewhere early on in the contributing guide. I guess my thought here is make it easy for someone who asks "I want to contribute, but I don't know what is the best way. How do I get started and what should I contribute?" to find the answer to that question. My general thought is that currently the contributing guide goes into good detail about how things are structured and why things are the way they are. This is good for someone who reaches the stage of "I know what I want to contribute. Now that I know that, let's see how I go about making it happen." I think a great addition would be something like the list above to help people get to that stage.

I'd like to figure out how to make it so that those types of questions are answered up front, and that people should be comfortable asking them (for example here in the discussions repository).

I know I had questions when I first joined, though I can only speak for myself and I don't know what would work for everyone in general. The contributing guide does have a sentence offering that questions can be asked of you via email; but perhaps there's more? What kinds of questions did you envision people having?

kytrinyx commented 8 years ago

It could probably be put in a more prominent location and made clear that you can "Contribute on Github" or "Get Involved!" or something that makes clear that ideas are welcome.

Yeah, definitely. I worry about overloading the homepage too much, but I think that if it's a clearly different section, then you don't have to read it at all, and it might not come across as "wall of text".

I think such a list should go somewhere early on in the contributing guide.

Yes, I think you're right.

What kinds of questions did you envision people having?

I have no idea--which I think is the main problem :)

petertseng commented 8 years ago

What kinds of questions did you envision people having?

I have no idea--which I think is the main problem :)

Hmm. I will attempt to speak for myself. It would be great to hear ideas from others who had questions in the past.

One common question may be: "So what does it mean if I'm a maintainer? What will my responsibilities be". I suspect the answers are well contained in https://github.com/exercism/x-common/blob/master/CONTRIBUTING.md#maintaining-a-track, but say the word if it could be improved somehow.

I think another will be some variant of "But I'm not fit for this task!" or "But I'm not even that good at this language, how can I be a maintainer for the track for it?". This question can get complex to answer. For me personally, it helped to know that 1) well, if I was being asked clearly someone thinks I'm at a good enough level, even if not the best 2) it's not like I'm maintaining the compiler for the language and 3) treat it as a learning opportunity! Again, suggestions on answers here will be useful if people think this will be a common question.

kytrinyx commented 8 years ago

"But I'm not even that good at this language, how can I be a maintainer for the track for it?

Yeah, I think this is an important one, and all of your answers are good ones. Not all of the maintainers need to be experts in the language; it is also about having a second or third person to be able to discuss ideas and trade-offs with as much as having an expert to sign off on whether or not a change is good. Some changes are obvious and easy to merge (typos, for example), others require more thought and discussion.

masters3d commented 8 years ago

I'd like to help maintain the objective-c track. (I got a PR waiting to get pulled in) It would be really helpful to have somebody else to bounce ideas in the swift track. I'd like nominate @robtimp to help with the swift track since he has done a bunch of PR already.

kytrinyx commented 8 years ago

@masters3d Done and done. For some reason I thought you were already a contributor on the Objective-C track. I'll add you there now. I'll also make both you and Hank team maintainers on the swift track so that you can add whoever you like (provided that they want to be added, of course!).

robtimp commented 8 years ago

@masters3d @kytrinyx I'd be happy to help out however I can with Swift or Objective-C.

kytrinyx commented 8 years ago

Thanks, Rob! I've given you commit.

roseaboveit commented 8 years ago

Is the checklist up to date at the moment? It looks like we had some takers for Objective-C in the discussion above.

I like the idea of a short survey to send out every few months or so, thanking people for their service as a language maintainer and then checking to see if they have any issues and checking in to ensure they'd like to continue serving as a maintainer. I'm thinking radio buttons and an optional text field. If they'd like to move on from maintaining, we can then ask the followup question of if there are any recommendations they have for recruiting a new maintainer so we have some leads for the hand-off.

kytrinyx commented 8 years ago

Is the checklist up to date at the moment?

Thanks @roseaboveit I forgot to update the list. I have added a maintainer to haskell, so it's gone from orphaned to at risk.

I like the idea of a short survey to send out every few months or so, thanking people for their service as a language maintainer and then checking to see if they have any issues and checking in to ensure they'd like to continue serving as a maintainer.

Yes, this would be excellent. I also want to add documentation that explicitly says that maintainers should never feel bad about moving on from the project, which we can then refer to in the survey. https://github.com/exercism/discussions/issues/36

kytrinyx commented 8 years ago

Suggestion from @marianaIAm

we could put a badge or label or something on exercism.io/languages next to tracks that need (more) maintainers - clicks to a documentation page about how to get involved as a maintainer.

Maybe we should suggest that a maintainer should be able to get through the entire track, but maybe that's not necessary.

tleen commented 7 years ago

Closing in favor of overarching discussion in #191.