[OH-Dev] issue tracker improvements - cleanliness, mentors, deadlines, etc

[Shauna Gordon-McKeon]

It seems like many open source projects, including ourselves, have some
problems keeping the issue tracker up to date.  While people generally try
to be conscientious, it's inevitable that without a system issues will fall
through the cracks.  We're not too bad about it, but just yesterday we had
a newcomer try to solve an already-fixed problem, and I've seen some
otherwise great projects be un-recommendable because I never know if a bug
in their issue tracker is fixed or not.

I want to solve this problem for OpenHatch, both to make the experience of
contributing to us better for our community, and because solutions could
then be recommended to other projects.

What if we made it OpenHatch policy that every pull request include a link
to the pull request it addresses (or an explanation of why it isn't in
response to an issue). Then every set period of time (or # of commits, or
lines of code changed), a maintainer could go through and make sure the
issues affected were closed as needed.

Pros:  Creates a structure for periodically cleaning the issue tracker, and
makes it easier for whoever is doing so to spot issues that need to be
closed by providing clear links between issues and pull requests.

Cons:  Still a lot of work for the cleaning maintainer (though less if done
regularly).

Optionally, one could write a script that goes through pull requests to see
what issues they're linking, and then looks through the bug tracker, and
alerts OH to any open bugs which have pull requests associated with them.
 This seems like it would make cleaning the tracker more efficient, though
it wouldn't help with bugs that don't get addressed via pull requests.

Additional thoughts:

- I also want to float the idea of explicitly identifying bugs for
newcomers.  It seems like we do this with "bitesize" bugs, but:
    - The main view for that is
this<http://openhatch.org/bugs/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignedto%2Cstatus%2Cmilestone&%40sort=activity&%40group=priority&%40search_text=bitesize&submit=Search>
which
shows resolved bugs (ideally we should point folks to a list containing
only things they could work on).
    - Also there's like nothing on it.
    - Also also it's some sort of secret that how you find newcomer-bugs is
to enter "bitesize" into the search bar.

- For each bug, a "mentor" could be assigned.  Other people can totally
help a newcomer with that bug, but the mentor is someone who is definitely
a) able and b) willing to help.

- For each bug, a deadline could be assigned.  After a certain period (2
months?) if no one has addressed it, we should take care of it - just
because a bug is small doesn't mean we don't need it resolved.  And
providing a deadline may make us more likely to label something as
bitesize, if we know it won't just be sitting unfixed indefinitely.

- We should have fields or at least prompts in the "New Issue" form for the
information that we stress, during events, should be put in an issue
tracker.  (What OS are you on?  What is expected vs actual behavior?  Etc.)
For anything being labelled bitesize we should arguably require those
fields.

I know that's a lot of stuff, but I think OpenHatch could really benefit
from improving these aspects.  OpenHatch's service to the open source world
is not just to be a welcoming community but to model concrete "welcoming"
behaviors, and I think this is another area where we can definitely improve.

-- Shauna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhatch.org/pipermail/devel/attachments/20131112/182a1876/attachment.html>