On 12/07/2016 08:56 PM, Joel Nothman wrote:
And yet GitHub just rolled out a new "reviewers" field for assigning
these things...
Yeah I'm not sure what the difference is from assignment.
I guess they thought as "assignment" for issues and reviewers for PRs?
But assignments also exist for PR
And yet GitHub just rolled out a new "reviewers" field for assigning these
things...
On 7 December 2016 at 03:26, Raghav R V wrote:
> +1 for self assigning PRs by reviewers...
>
> On Tue, Dec 6, 2016 at 4:19 PM, Andy wrote:
>
>> Thanks for your thoughts.
>> I'm working in a similar mode, though
+1 for self assigning PRs by reviewers...
On Tue, Dec 6, 2016 at 4:19 PM, Andy wrote:
> Thanks for your thoughts.
> I'm working in a similar mode, though I kind of try to avoid too much
> last-in first-out - I do it too, though,
> because I'm trying to keep up with all notifications.
> However,
Thanks for your thoughts.
I'm working in a similar mode, though I kind of try to avoid too much
last-in first-out - I do it too, though,
because I'm trying to keep up with all notifications.
However, there are many older PRs and issues that are important
bug-fixes and they get lost because of s
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 communicati
>
> 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
On 12/03/2016 01:20 PM, Nelle Varoquaux wrote:
On 3 December 2016 at 10:08, Andy wrote:
On 12/03/2016 12:26 PM, Raghav R V wrote:
We could start with assigning priority labels like they use in numpy...
That + milestones could help us prioritize?
I feel milestones are too coarse. Or I'm us
On 3 December 2016 at 10:08, Andy wrote:
>
>
> On 12/03/2016 12:26 PM, Raghav R V wrote:
>>
>> We could start with assigning priority labels like they use in numpy...
>> That + milestones could help us prioritize?
>>
> I feel milestones are too coarse. Or I'm using them wrong.
> And priority label
On 12/03/2016 12:26 PM, Raghav R V wrote:
We could start with assigning priority labels like they use in
numpy... That + milestones could help us prioritize?
I feel milestones are too coarse. Or I'm using them wrong.
And priority labels only work if people don't use the "high priority"
all
We could start with assigning priority labels like they use in numpy...
That + milestones could help us prioritize?
On Sat, Dec 3, 2016 at 11:52 AM, Gael Varoquaux <
gael.varoqu...@normalesup.org> wrote:
> On Fri, Dec 02, 2016 at 07:52:09PM -0500, Andy wrote:
> > So did we ever decide on how to p
On Fri, Dec 02, 2016 at 07:52:09PM -0500, Andy wrote:
> So did we ever decide on how to prioritize reviews?
I don't know how to do this.
> I think it might be helpful if Joel and me prioritize issues.
I think that it would be useful. Although of course different people will
have different priori
Another fun shortcoming of the project interface:
If a card is already present in your project, you can not search for it
(though you can ctrl+f)
___
scikit-learn mailing list
scikit-learn@python.org
https://mail.python.org/mailman/listinfo/scikit-lear
Hey Nelle.
That sounds great. My main question is how you'd expose this to the user.
Will it be a separate website? A bot? Emails? Greasemonkey on top of github?
Most of these could be implemented with tags that are automatically
assigned by a bot, I guess.
That would be quite a few tags, thoug
Hello,
This seems a good moment to say that we will be starting a project at
BIDS next semester to try extract information from github and classify
PRs into different categories (stalled, updated, needs review).
Stéfan drafted a list of elements he would like to see for
scikit-image, and I have be
So did we ever decide on how to prioritize reviews?
(I was still mentally / notification catching up after 0.18.1)
There are some really important issues to tackle, often with proposed
solutions, not no reviews!
It's hard for everybody to keep the big picture in mind with such a full
issue trac
The spreadsheet seems to have some duplications and presumably some missing
rows, with apologies. I assume some is due to the github pagination, and
some may be my error. Not a big enough error to fix up.
On 30 September 2016 at 05:15, Raphael C wrote:
> My apologies I see it is in the spreadshe
My apologies I see it is in the spreadsheet. It would be great to see
this work finished for 0.19 if at all possible IMHO.
Raphael
On 29 September 2016 at 20:12, Raphael C wrote:
> I hope this isn't out of place but I notice that
> https://github.com/scikit-learn/scikit-learn/pull/4899 is not in
I hope this isn't out of place but I notice that
https://github.com/scikit-learn/scikit-learn/pull/4899 is not in the
list. It seems like a very worthwhile addition and the PR appears
stalled at present.
Raphael
On 29 September 2016 at 15:05, Joel Nothman wrote:
> I agree that being able to iden
On 29 September 2016 at 10:41, Nelson Liu wrote:
> I think it's a matter of two things -- one, you can't be assigned if you
> aren't a member of the organization on github. Two -- linking pull requests
> to issues is generally visible enough (hence why it's in the PR template).
> We don't have iss
I think it's a matter of two things -- one, you can't be assigned if you
aren't a member of the organization on github. Two -- linking pull requests
to issues is generally visible enough (hence why it's in the PR template).
We don't have issues with figuring out who is working on an issue, but
rath
I have a question which may/may not be relevant here. The question is why
don't we assign issues to the one who have asked to take this issue. This
feature may give us a better picture of the current stat of the Issue. We
can ping that person directly and get info regarding his progress in case
of
I've put a column for that status in.
Note: this has largely been generated with
https://gist.github.com/jnothman/8eba0834acfd633c6d83b437f6f18c49
On 30 September 2016 at 00:16, Guillaume Lemaître
wrote:
> What do you think about splitting MRG and MRG+1 in two different column.
> The scrolling
What do you think about splitting MRG and MRG+1 in two different column.
The scrolling can get a little bit less annoying and you can have an easier
view on the MRG+1 to kick them out.
___
scikit-learn mailing list
scikit-learn@python.org
https://mail.pyt
I agree that being able to identify which PRs are stalled on the
contributor's part, which on reviewers' part, and since when, would be
great. I'm not sure we've come up with a way that'll work though.
In terms of backlog, I've wondered if just getting things into a
spreadsheet would help:
https:
So I made a project for 0.19:
https://github.com/scikit-learn/scikit-learn/projects/5
The idea would be to drag and drop issues and PRs so that the important
ones are at the top.
We could also add an "important" column, currently the scrolling is
pretty annoying.
Thoughts?
On 09/28/2016 03
On 28 September 2016 at 12:24, Andreas Mueller wrote:
>
>
> On 09/28/2016 02:21 PM, Nelle Varoquaux wrote:
>>
>>
>> I think the only ones worth having are the ones that can be dealt with
>> automatically and the ones that will not be used frequently:
>>
>> - stalled after 30 days of inactivity [ca
On 09/28/2016 02:21 PM, Nelle Varoquaux wrote:
I think the only ones worth having are the ones that can be dealt with
automatically and the ones that will not be used frequently:
- stalled after 30 days of inactivity [can be done automatically]
- in dispute [I don't expect it to be used often
On 28 September 2016 at 10:09, Nelson Liu wrote:
> Maybe something for "stalled" pull requests? e.g. if someone hasn't worked
> on their PR in say 30 days and it's tagged "waiting for changes", you could
> ping them and then put on the "stalled" label. If they don't respond in
> another 15 days /
Maybe something for "stalled" pull requests? e.g. if someone hasn't worked
on their PR in say 30 days and it's tagged "waiting for changes", you could
ping them and then put on the "stalled" label. If they don't respond in
another 15 days / say they aren't working on it anymore, maybe it'd be good
So following up on this conversation, do we want to use status labels
more consistently?
And what should they be?
Joel Proposed for PRs:
* WIP (not ready for review)
* waiting for review [we have a tag for this]
* waiting for changes (with or without one of the following)
* in dispute (i.e. fund
On 21 September 2016 at 22:13, Andreas Mueller wrote:
>
>
> On 09/19/2016 09:56 PM, Nelle Varoquaux wrote:
>>>
>>> Another bot-able tool might be pinging inactive PRs to ask if they're
>>> being
>>> worked on, and labelling "Needs contributor" if there's no reply within n
>>> days...!
>
> That kin
On 09/19/2016 09:56 PM, Nelle Varoquaux wrote:
Another bot-able tool might be pinging inactive PRs to ask if they're being
worked on, and labelling "Needs contributor" if there's no reply within n
days...!
That kind of only works when the status is "waiting for changes",
and not "waiting for r
> Another bot-able tool might be pinging inactive PRs to ask if they're being
> worked on, and labelling "Needs contributor" if there's no reply within n
> days...!
If PRs are inactive, it might also be interesting to tag them as
easy_fix when there is little to do.
>
> On 20 September 2016 at 00
Another bot-able tool might be pinging inactive PRs to ask if they're being
worked on, and labelling "Needs contributor" if there's no reply within n
days...!
On 20 September 2016 at 00:05, Joel Nothman wrote:
> On 17 September 2016 at 01:21, Gael Varoquaux <
> gael.varoqu...@normalesup.org> wro
On Mon, Sep 19, 2016 at 4:06 PM Joel Nothman wrote:
> I think it would be worth trying to have a rough *priority ranking for
> things we'd like to see in 0.19*. However the Github Milestones feature
> is a bit crippled in UI: you can rank issues, but cannot filter by anything
> but open/closed, s
On 17 September 2016 at 01:21, Gael Varoquaux wrote:
> On Fri, Sep 16, 2016 at 09:14:12AM +1000, Joel Nothman wrote:
> > 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).
>
> Yes, I
On Fri, Sep 16, 2016 at 09:14:12AM +1000, Joel Nothman wrote:
> 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).
Yes, I do that a lot. So this is not a great improvement for me.
G
___
On 09/16/2016 01:14 AM, Joel Nothman wrote:
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 to
gt; 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
>> S
: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 q
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
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
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 t
43 matches
Mail list logo
