[scikit-learn] Github project management tools

[Joel Nothman]

With apologies for starting the thread and then disappearing for a while
(life got in the way, and when I came back I decided the issue backlog
itself was more pressing):

Of late, I mostly operate on a last-in-first-out basis, so I'm highly
influenced by recent activity. This minimises communication time and issues
due to fading memories of contributors and reviewers. This preferences bug
fixes, and is less good for long-term feature needs; but that preference
also aligns with my ability to get through a small unit of work much more
easily than a large conceptual PR. Sometimes I push things onto the stack
that I recall I would like to see merged. From a personal perspective,
having a way to remind myself of these priorities would be valuable.

I'm not convinced the *Projects* kanban feature is going to readily help
us, unfortunately. I don't think the problem is so much about staging
issues so much as just maintaining a prioritised backlog. The Projects
feature is poor with *long* lists of issues, and that's where we're at.

Apart from bug fixes, I think there are *two main things that we should
keep a list of*:
1. enhancements/features that a few people are agreed we'd like to see, but
may get lost in the wash.
2. big ideas that need concentrated design/development work from multiple
people. For example: estimator tags, sample properties, feature names,
?increased pandas support (which incidentally solves the latter two
issues!), etc.

What belongs in 1. is very hard to define, but it could be easily
maintained through some kind of "Forget me not!" label (alternatively just
"high priority").

Managing 2 is more about resolving some epic-scale goals as part of a
release plan, and then managing a particular project to achieve design
consensus, development tasking and review. While some of this can be
managed with labels / kanban boards, this is mostly a procedural issue
about establishing virtual sprints: we need a way to design release goals.

In terms of *Milestones*: I don't find it useful for us to assign general
issues to future milestones. Where version milestones can be useful is to
say "include this in a bug-fix release" or "save this for a major release"
(i.e. might break backwards compatibility in a big way). These also allow
us to avoid postponing releases excessively: we can scope a release 6 weeks
before its proposed date, and say that as long as we can merge or eliminate
nearly every issue associated with it, we should delay no longer.

The other thing that I notice is that it's not always clear who is
available to review a particular contribution. GitHub allows one or more
*Assignees* (must be team members) to be appointed to an issue / PR. While
it is often useful to have more than two sets of eyes, using the Assignees
feature may mean that each of us can better focus on a small set of issues.
Upon seeing a PR that they think they will have capacity and expertise to
review, core devs could assign themselves to its review, with the advantage
of minimising duplicated work, while creating a sense of voluntary duty
commensurate with each contributor's availability.

Apologies that I don't really have a TL;DR or any explicit proposals, but I
hope you find my thoughts here useful.

Joel

On 5 December 2016 at 03:16, Raghav R V <ragvrv at gmail.com> wrote:

> Okay so in the project, instead of sorting them by Issues / PR why don't
>>>> we make one column per priority. Let's have 3 levels and one column for
>>>> Done. We have a label for "Stalled" / "Need Contributor" which shows up in
>>>> the cards of the project anyway...
>>>>
>>>> As I didn't want to disturb the existing project setup, I created one
>>>> for a demo - https://github.com/scikit-learn/scikit-learn/projects/7
>>>> (I'm resending this e-mail as the last one was rejected because the
>>>> attached image was huge for the mailing list)
>>>>
>>>
> Thanks
>
> Raghav
>
> _______________________________________________
> scikit-learn mailing list
> scikit-learn at python.org
> https://mail.python.org/mailman/listinfo/scikit-learn
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-learn/attachments/20161206/0e83d53e/attachment.html>