<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hey Joel.<br>
Thanks for bringing this up. I have a really hard time keeping up
with what's happening<br>
on the issue tracker and I have no idea how you manage.<br>
<br>
The current tags are certainly not always helpful. Also, they are
rarely updated.<br>
<br>
I have been very frustrated by github. I used email to track all
issues, but their new "upgrade"<br>
made that impossible as issues are no longer email threads - each
review is it's own thread.<br>
<br>
It might make sense to switch to something like reviewable or
gerrit.<br>
These sit on top of github, and people can interact with them
without using them.<br>
I haven't really worked with either, but heard only good things
about them.<br>
<br>
Any way to prioritize issues and putting them into the buckets that
you listed would be a great step forward.<br>
That would require someone manually going through 470 PRs and 762
issues, though.<br>
I would be happy to do that if we actually stick to the system. A
single person is not enough to keep the tags (or whatever we end up
using)<br>
up to date, though.<br>
<br>
Your statuses only apply to PRs, too, and we need to have something
similar for issues, which have maybe these statuses<br>
<br>
* random idea / feature request<br>
* feature request with consensus to implement<br>
* possible bug<br>
* confirmed bug<br>
* feature request or bug with active PR<br>
* feature request or bug with stale PR<br>
<br>
One problem with these is that man feature requests never get any
comments, similar for PRs.<br>
Is a PR without comment waiting for review? Or in dispute?<br>
A PR could be reviewed but dispute could happen later, as we don't
always agree on what to do.<br>
<br>
I agree that we should try to organize ourselves better. I'm
doubtful the new github features will help.<br>
They certainly already have tremendously hindered me in keeping up
in the couple of hours they've been online.<br>
<br>
There is still no way to mark a comment as addressed, and comments
are still more or less randomly hidden<br>
(and links to them become dead). Both of these issues are fixed in
the other review platforms.<br>
<br>
I don't think we are the intended users of github, though I'm not
sure who is.<br>
<br>
<br>
<div class="moz-cite-prefix">On 09/15/2016 07:14 PM, Joel Nothman
wrote:<br>
</div>
<blockquote
cite="mid:CAAkaFLXw7+Qfu1L+SGijrVGJ7UU=R-tx4_ttdh0fCJo-u53fMw@mail.gmail.com"
type="cite">
<div dir="ltr">One of the biggest issues with scikit-learn as a
project is managing its backlog of issues; another is release
scheduling. Some of this cannot be fixed as long as our model of
voluntary contribution (with a couple of important exceptions)
does not change. However, it may be worth considering the new
project management features in Github.
<div><br>
</div>
<div>At the moment we have the following management:</div>
<div>* labels corresponding to type (bug, enhancement, new feat,
question), scope (API, Build/CI, ?Large Scale, Documentation),
difficulty (easy, moderate), status/scheduling (needs
contributor, needs review, sprint).</div>
<div>* PR status management with title prefixes [WIP], [MRG],
[MRG+1], [MRG+2]</div>
<div><br>
</div>
<div>Firstly, we might benefit from prefixing labels by
category, i.e. difficulty:easy so that complementary labels
appear together.</div>
<div><br>
</div>
<div>In truth, PRs have roughly these statuses:</div>
<div>* WIP (not ready for review)</div>
<div>* waiting for review</div>
<div>* waiting for changes (with or without one of the
following)</div>
<div>* in dispute (i.e. fundamental doubts about the PR)</div>
<div>* the above together with 1 or 2 "official" approvals</div>
<div>* ready for merge (pending minor changes such as what's new
documentation)</div>
<div><br>
</div>
<div>New github features:</div>
<div><br>
</div>
<div>* reviews with "approved" or "request changes". A list of
approvers can be found in the merge/CI panel. We could replace
the MRG+1 annotation with this and use it to track disputation
too. I'm not sure how it works with changes that are added
after approval. I think it would have avoided one improper
merge by me... One downside is that there does not yet seem to
be a way to search for PRs with a specified level of approval
(while searching for "MRG+1" sort-of works).</div>
<div>* Milestone prioritising: issues in a milestone, such as <a
moz-do-not-send="true"
href="https://github.com/scikit-learn/scikit-learn/milestone/21">https://github.com/scikit-learn/scikit-learn/milestone/21</a>,
can be ranked with drag-and-drop. I think this could help with
release scheduling as it would allow us to identify the top
priorities for a release and see when enough of them are
completed.</div>
<div>* The Kanban-style workflow management of the new Projects
tool <a moz-do-not-send="true"
href="https://github.com/scikit-learn/scikit-learn/projects">https://github.com/scikit-learn/scikit-learn/projects</a>
is another way of managing status and, I think, priority, for
a small set of related issues. This might be an alternative
way of managing milestone scope, or of working towards big
changes like the one just completed for model selection; like
proposed expansions to get_feature_names expansion; like
estimator tags; making utilities public/private...</div>
<div><br>
</div>
<div>So with the goal of making it easier to track where
attention is most needed, and when to move to release: What's
worth trying?</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
scikit-learn mailing list
<a class="moz-txt-link-abbreviated" href="mailto:scikit-learn@python.org">scikit-learn@python.org</a>
<a class="moz-txt-link-freetext" href="https://mail.python.org/mailman/listinfo/scikit-learn">https://mail.python.org/mailman/listinfo/scikit-learn</a>
</pre>
</blockquote>
<br>
</body>
</html>