> 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.

Yeah, I would that moving away from GitHub involves probably too much hassle 
given the size of the project. Also, I don’t think there are any good 
alternatives besides BitBucket, which also would be not a good choice for such 
a big project due to its pricing structure — they have a simple yet useful 
“priority” attribute for issues though. Not sure, but it feels like GitHub is 
currently in a somewhat experimental stage regarding their web UI — feels like 
they are changing a bit too much, too often frequently. However, maybe (or 
hopefully) they'll address a few of the recent annoyances in future due to user 
feedback. Using a wrapper seems like a good idea right now, but who knows 
whether or not these wrapper will introduce changes as well in near future. 

>> either through the milestone feature, the project feature

I think the milestone feature is pretty useful. Have seen this in several other 
projects (e.g., matplotlib). As a user/sometimes contributor, it would help 
with focussing on more important issues; I am sometimes a bit hesitant to 
submit/tackle pull requests or issues since I feel like they are somewhat 
distracting the core contributors from the more important stuff.

Best,
Sebastian

> On Sep 16, 2016, at 9:11 AM, Sebastian Raschka <se.rasc...@gmail.com> wrote:
> 
> 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

_______________________________________________
scikit-learn mailing list
scikit-learn@python.org
https://mail.python.org/mailman/listinfo/scikit-learn

Reply via email to