New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider merging labels `up-for-grabs` and `accepting prs` labels #455

Closed
terrajobst opened this Issue Jan 17, 2015 · 6 comments

Comments

Projects
None yet
8 participants
@terrajobst
Member

terrajobst commented Jan 17, 2015

As discussed here it seems that these labels are semantically so close that it may make sense for us to merge them.

  • up-for-grabs. This is meant for tagging issues to indicate that we'd like the help of the community.
  • accepting pr. We use this label as part of the API review process. It's tagging proposals for API additions to indicate that we're happy to review & accept pull requests for those.

It seems they are conceptually both doing the same thing: they are indicating to our community that we're happy if they jump in and help.

Thoughts?

@akoeplinger

This comment has been minimized.

Show comment
Hide comment
@akoeplinger

akoeplinger Jan 17, 2015

Member

Well, if we go back to the original intention for up-for-grabs (i.e. as it says on the website: "a list of projects which have curated tasks specifically for new contributors"), I'd say accepting-prs issues are certainly on the heavy side and not something I'd recommend for new/inexperienced contributors. It might make sense to keep both and use up-for-grabs to tag simple things like cleaning up some test code or fixing formatting.

Then again, this is quite a high-profile project so people will likely understand that not every up-for-grabs task is a simple one :)

Member

akoeplinger commented Jan 17, 2015

Well, if we go back to the original intention for up-for-grabs (i.e. as it says on the website: "a list of projects which have curated tasks specifically for new contributors"), I'd say accepting-prs issues are certainly on the heavy side and not something I'd recommend for new/inexperienced contributors. It might make sense to keep both and use up-for-grabs to tag simple things like cleaning up some test code or fixing formatting.

Then again, this is quite a high-profile project so people will likely understand that not every up-for-grabs task is a simple one :)

@AlexArchive

This comment has been minimized.

Show comment
Hide comment
@AlexArchive

AlexArchive Jan 17, 2015

Personally I have always perceived up-for-grabs to mean low-hanging-fruit.

From http://up-for-grabs.net/:

  • Tasks should take no longer than a few nights' worth of work
  • Tasks should stand alone - avoid core functionality on which other tasks depend
  • Tasks should be well described with pointers to help the implementer

Maybe this definition is applicable to both labels? If yes, merge them; otherwise, perhaps it would be worthwhile to maintain both labels.

AlexArchive commented Jan 17, 2015

Personally I have always perceived up-for-grabs to mean low-hanging-fruit.

From http://up-for-grabs.net/:

  • Tasks should take no longer than a few nights' worth of work
  • Tasks should stand alone - avoid core functionality on which other tasks depend
  • Tasks should be well described with pointers to help the implementer

Maybe this definition is applicable to both labels? If yes, merge them; otherwise, perhaps it would be worthwhile to maintain both labels.

@weshaggard

This comment has been minimized.

Show comment
Hide comment
@weshaggard

weshaggard Jan 17, 2015

Member

I actually think these should be two different concepts as well. I also consider up-for-grabs to be more low-hanging-fruit where as the current accepting-pr could be an entire feature ranging from tiny to extra large. Perhaps we should just rename accepting-pr to something else. The purpose really is to make sure someone in the community doesn't go off and do a lot of work before discussing it with the owners. So the tag is really a message to the community that the owners agree with the direction and people should feel free to start coding. So perhaps we should rename the tag to something like feature-approved or something along those lines.

Member

weshaggard commented Jan 17, 2015

I actually think these should be two different concepts as well. I also consider up-for-grabs to be more low-hanging-fruit where as the current accepting-pr could be an entire feature ranging from tiny to extra large. Perhaps we should just rename accepting-pr to something else. The purpose really is to make sure someone in the community doesn't go off and do a lot of work before discussing it with the owners. So the tag is really a message to the community that the owners agree with the direction and people should feel free to start coding. So perhaps we should rename the tag to something like feature-approved or something along those lines.

@nguerrera

This comment has been minimized.

Show comment
Hide comment
@nguerrera

nguerrera Jan 17, 2015

Member

I like feature-approved. One issue with accepting-pr is that in many cases the person who filed the issue intends to code it. accepting-pr suggests it's now up for anyone to do. Perhaps we could put both feature-approved and accepting-pr in the cases where it was reviewed but nobody is signed up for it?

Member

nguerrera commented Jan 17, 2015

I like feature-approved. One issue with accepting-pr is that in many cases the person who filed the issue intends to code it. accepting-pr suggests it's now up for anyone to do. Perhaps we could put both feature-approved and accepting-pr in the cases where it was reviewed but nobody is signed up for it?

@terrajobst terrajobst self-assigned this Jan 18, 2015

@shiftkey

This comment has been minimized.

Show comment
Hide comment
@shiftkey

shiftkey Jan 18, 2015

As the one who raised the issue (and helps look after up-for-grabs) I love this thread clarifying things for me. A couple of quick thoughts:

  • The size of the work required is definitely key - perhaps unifying them isn't right, as you want to ensure new contributors don't end up in some sort of fresh hell.
  • after understanding the accepting-prs label, i do like the suggestion of renaming it to make it's purpose/intent clearer
  • I totally missed this section in the process of reading documentation (my bad!).

shiftkey commented Jan 18, 2015

As the one who raised the issue (and helps look after up-for-grabs) I love this thread clarifying things for me. A couple of quick thoughts:

  • The size of the work required is definitely key - perhaps unifying them isn't right, as you want to ensure new contributors don't end up in some sort of fresh hell.
  • after understanding the accepting-prs label, i do like the suggestion of renaming it to make it's purpose/intent clearer
  • I totally missed this section in the process of reading documentation (my bad!).
@ellismg

This comment has been minimized.

Show comment
Hide comment
@ellismg

ellismg Feb 8, 2015

Contributor

Based on the new guidance on the Wiki for how we deal with issues, we'll keep two labels for work which is approved but currently unclaimed. "up for grabs" for small items we think are well scoped and would be approachable by someone new to CoreFx and "feature approved" for larger scale work.

Contributor

ellismg commented Feb 8, 2015

Based on the new guidance on the Wiki for how we deal with issues, we'll keep two labels for work which is approved but currently unclaimed. "up for grabs" for small items we think are well scoped and would be approachable by someone new to CoreFx and "feature approved" for larger scale work.

@ellismg ellismg closed this Feb 8, 2015

@karelz karelz modified the milestone: 1.0.0-rtm Dec 3, 2016

Olafski pushed a commit to Olafski/corefx that referenced this issue Jun 15, 2017

Merge pull request #455 from leecow/master
Correct urls and update final RC3 build number
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment