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

terrajobst opened this Issue Jan 17, 2015 · 6 comments


None yet

8 participants


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.


@terrajobst terrajobst referenced this issue in up-for-grabs/ Jan 17, 2015

Added .NET Core to the project list #146

@terrajobst terrajobst added the Meta label 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 :)


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


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


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.


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

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 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment