Scikit-learn’s GitHub repo already makes use of these templates. I think the issue is more a technical one arising from their latest “style” changes.
> On Sep 16, 2016, at 8:25 AM, Dale T Smith <dale.t.sm...@macys.com> wrote: > > A form – with required, pre-defined fields – can help when people submit > bugs, issues, or requests for new features. Perhaps creating an issue > template for scikit-learn is a good first step. > > https://help.github.com/articles/creating-an-issue-template-for-your-repository/ > > Pull requests also have a template > > https://help.github.com/articles/creating-a-pull-request-template-for-your-repository/ > > I am not sure how these fit into the team’s review and release workflow. > > If this doesn’t quite fit your needs, perhaps engaging Github Support will > yield something interesting. > > __________________________________________________________________________________________ > Dale Smith | Macy's Systems and Technology | IFS eCommerce | Data Science > 770-658-5176 | 5985 State Bridge Road, Johns Creek, GA 30097 | > dale.t.sm...@macys.com > > From: scikit-learn > [mailto:scikit-learn-bounces+dale.t.smith=macys....@python.org] On Behalf Of > Joel Nothman > Sent: Friday, September 16, 2016 1:15 AM > To: Scikit-learn user and developer mailing list > Subject: Re: [scikit-learn] Github project management tools > > ⚠ EXT MSG: > I think we're quite close to the intended users of Github, they just started > simple and with all these more feature-complete competitors appear, are > adding those features but haven't quite got it right yet. I'm not convinced > that it's the perfect tool (although I haven't seen this threading problem; > gmail seems to still be keeping one thread per PR?), but its simplicity and > familiarity/popularity is a great advantage for handling new contributors. In > terms of contributor familiarity, most of the projects that we integrate with > use same: numpy, scipy, cython (recently), pandas, matplotlib, ipython. While > I appreciate that we are somewhat arbitrarily supporting a near-monopoly, the > case for moving away from, or even wrapping, github seems poor to me. > > Apart from distinguishing between possible bug, actual bug and other (which > are fairly static categories), classifying issues by status is too hard to > manage. What I'd like to suggest is that we choose a way to highlight > high-priority issues for the next release, either through the milestone > feature, the project feature. Other issues will still get attention by way of > random traffic, but we care less about the timing of their resolution. > > (I'm sure there must be a way using the API to find issues linked to by PRs > or not, but I don't think that's available in the UI.) > > On 16 September 2016 at 09:35, Andreas Mueller <t3k...@gmail.com> wrote: > Hey Joel. > Thanks for bringing this up. I have a really hard time keeping up with what's > happening > on the issue tracker and I have no idea how you manage. > > The current tags are certainly not always helpful. Also, they are rarely > updated. > > I have been very frustrated by github. I used email to track all issues, but > their new "upgrade" > made that impossible as issues are no longer email threads - each review is > it's own thread. > > It might make sense to switch to something like reviewable or gerrit. > These sit on top of github, and people can interact with them without using > them. > I haven't really worked with either, but heard only good things about them. > > Any way to prioritize issues and putting them into the buckets that you > listed would be a great step forward. > That would require someone manually going through 470 PRs and 762 issues, > though. > 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) > up to date, though. > > Your statuses only apply to PRs, too, and we need to have something similar > for issues, which have maybe these statuses > > * random idea / feature request > * feature request with consensus to implement > * possible bug > * confirmed bug > * feature request or bug with active PR > * feature request or bug with stale PR > > One problem with these is that man feature requests never get any comments, > similar for PRs. > Is a PR without comment waiting for review? Or in dispute? > A PR could be reviewed but dispute could happen later, as we don't always > agree on what to do. > > I agree that we should try to organize ourselves better. I'm doubtful the new > github features will help. > They certainly already have tremendously hindered me in keeping up in the > couple of hours they've been online. > > There is still no way to mark a comment as addressed, and comments are still > more or less randomly hidden > (and links to them become dead). Both of these issues are fixed in the other > review platforms. > > I don't think we are the intended users of github, though I'm not sure who is. > > > > On 09/15/2016 07:14 PM, Joel Nothman wrote: > 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. > > At the moment we have the following management: > * 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). > * PR status management with title prefixes [WIP], [MRG], [MRG+1], [MRG+2] > > Firstly, we might benefit from prefixing labels by category, i.e. > difficulty:easy so that complementary labels appear together. > > In truth, PRs have roughly these statuses: > * WIP (not ready for review) > * waiting for review > * waiting for changes (with or without one of the following) > * in dispute (i.e. fundamental doubts about the PR) > * the above together with 1 or 2 "official" approvals > * ready for merge (pending minor changes such as what's new documentation) > > New github features: > > * 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). > * Milestone prioritising: issues in a milestone, such as > https://github.com/scikit-learn/scikit-learn/milestone/21, 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. > * The Kanban-style workflow management of the new Projects > toolhttps://github.com/scikit-learn/scikit-learn/projects 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... > > 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? > > > _______________________________________________ > scikit-learn mailing list > scikit-learn@python.org > https://mail.python.org/mailman/listinfo/scikit-learn > > > _______________________________________________ > scikit-learn mailing list > scikit-learn@python.org > https://mail.python.org/mailman/listinfo/scikit-learn > > > * This is an EXTERNAL EMAIL. Stop and think before clicking a link or opening > attachments. > _______________________________________________ > scikit-learn mailing list > scikit-learn@python.org > https://mail.python.org/mailman/listinfo/scikit-learn _______________________________________________ scikit-learn mailing list scikit-learn@python.org https://mail.python.org/mailman/listinfo/scikit-learn
