<div dir="ltr">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):<div><br></div><div>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.</div><div><br></div><div>I'm not convinced the <b>Projects</b> 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 <i>long</i> lists of issues, and that's where we're at.</div><div><br></div><div>Apart from bug fixes, I think there are <b>two main things that we should keep a list of</b>:</div><div>1. enhancements/features that a few people are agreed we'd like to see, but may get lost in the wash.</div><div>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.</div><div><br></div><div>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").</div><div><br></div><div>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.</div><div><br></div><div>In terms of <b>Milestones</b>: 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.<br></div><div><br></div><div>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 <b>Assignees</b> (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.</div><div><br></div><div>Apologies that I don't really have a TL;DR or any explicit proposals, but I hope you find my thoughts here useful.</div><div><br></div><div>Joel</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 5 December 2016 at 03:16, Raghav R V <span dir="ltr"><<a href="mailto:ragvrv@gmail.com" target="_blank">ragvrv@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_600691922471236848gmail-HOEnZb"><div class="m_600691922471236848gmail-h5"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_600691922471236848gmail-m_3704460844397700458HOEnZb"><div class="m_600691922471236848gmail-m_3704460844397700458h5"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_extra"><div class="m_600691922471236848gmail-m_3704460844397700458m_-4036752656169368360h5"><span class="m_600691922471236848gmail-im" style="font-size:12.8px"><span class="m_600691922471236848gmail-m_3704460844397700458gmail-im" style="font-size:12.8px"><span style="font-size:12.8px">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...</span></span><div style="font-size:12.8px"><br></div></span><div style="font-size:12.8px">As I didn't want to disturb the existing project setup, I created one for a demo - <a href="https://github.com/scikit-learn/scikit-learn/projects/7" target="_blank">https://github.com/scikit-le<wbr>arn/scikit-learn/projects/7</a></div><div class="m_600691922471236848gmail-yj6qo m_600691922471236848gmail-ajU" style="font-size:12.8px"><div id="m_600691922471236848gmail-:2tk" class="m_600691922471236848gmail-ajR"><img class="m_600691922471236848gmail-ajT" src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif" style="opacity:0.3"></div></div><div class="m_600691922471236848gmail-adL" style="font-size:12.8px"><span class="m_600691922471236848gmail-im"><div style="font-size:12.8px"><span style="font-size:12.8px">(I'm resending this e-mail as the last one was rejected because the attached image was huge for the mailing list)</span></div></span></div></div></div></blockquote></div></div></div></div></blockquote></div></div></div></div></blockquote><div><br></div><div>Thanks</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Raghav </div></font></span></div>
<br>______________________________<wbr>_________________<br>
scikit-learn mailing list<br>
<a href="mailto:scikit-learn@python.org">scikit-learn@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/scikit-learn" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/scikit-learn</a><br>
<br></blockquote></div><br></div>