As discussed here it seems that these labels are semantically so close that it may make sense for us to merge them.
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.
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?
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:
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.