Change "up for grabs" label to up-for-grabs

[karelz]

The up-for-grabs label is "more" standard -- see e.g. http://up-for-grabs.net and we used to have it in CoreCLR repo, but changed it to CoreFX form in ~2016/10

• Rename label on all repos
• Update docs in repos:
  • CoreFX: "up for grabs" and "up%20for%20grabs" - PR: change link for up-for-grabs issues corefx#17544 and Update up-for-grabs label corefx#17594
  • CoreCLR: "up for grabs" and "up%20for%20grabs" - PR: Fix link for up-for-grabs issues coreclr#10488
  • Roslyn: "Up for Grabs" and "Up%20for%20Grabs" - PR: propsed change for up-for-grabs label roslyn#18197
  • wcf - PR: change link to new label for up-for-grabs wcf#1827 and dotnet/wcf@1f343b2
  • CoreRT - PR: Fix up-for-grabs link corert#3121
  • cli - "help wanted" renamed to up-for-gras, no doc changes needed
  • sdk - no doc changes needed
  • CoreFXLab - no doc changes needed
• Update http://up-for-grabs queries for all repos:
  • CoreFX, Roslyn, CoreFXLab - PR Update up-for-grabs label in dotnet/CoreFX, dotnet/CoreFXLab and dotnet/Roslyn repos up-for-grabs/up-for-grabs.net#577 and PR Fix names of the new up-for-grab URLs up-for-grabs/up-for-grabs.net#579
  • CoreCLR - already OK
  • wcf, corert, cli, sdk - not present on http://up-for-grabs.net
• Find out if we can have 'simple' query on the site as well - issue filed Question: Can we provide 2 queries per repo? up-for-grabs/up-for-grabs.net#578

See dotnet/coreclr#10488 (comment)

cc @jkotas

[JonHanna]

Something that's occurred to me occasionally is whether the judgements that an issue would likely be a good one for a newbie to corefx should be a label. There's been a couple of times I was asked for advice on getting started as a contributor and being able to point to a label as having good issues to start with would have been good. And of course, it could also be linked to from the docs.

So, maybe a newcomer-friendly label, or a set of estimated complexity labels would complement up-for-grabs fruitfully.

[karelz]

@JonHanna good point - we have label simple, however, we didn't start using it too much. It was created after most areas went through initial triage.
We can probably sweep through the issues and do that ...

Docs are a bit behind on targeting new contributors :( - something on my TODO list since December :( ... if anyone wants to help with that, that would be great -- see dotnet/corefx#17534.

[karelz]

I plan to run the renaming by all area owners in CoreFX and CoreCLR on Monday. They might have existing queries, etc., so I want to make sure it is not a surprise for them and that there is not strong push back.

BTW: After looking deeper at various projects on http://up-for-grabs.net, I have noticed that quite a lot of them use different names ("Help wanted", help-wanted, up_for_grabs, "Up for grabs", jump-in, "jump in", etc.)
From that perspective, I am not sure if the rename is worth it. Roslyn uses "Up for Grabs", so unless @jaredpar is ok with a change, we won't be consistent across all our core repos anyway.

On personal side: common labels with spaces are a bit pain in queries, and up-for-grabs is the recommendation, so I don't mind changing it ;).

[jkotas]

we have label simple, however, we didn't start using it too much. It was created after most areas went through initial triage.

The up-for-grabs issues are meant to be simple: a few nights worth of work, standalone, non-ambiguous tasks if we are following the spirit of http://up-for-grabs.net/. However, the label has been sometimes used to mean "I do not plan to work on this anytime soon" here. Older issues that have been opened during the period where we insisted on all issue to be assigned to somebody tend to suffer from this more.

[karelz]

up-for-grabs is not only for "simple newbie" things, however they should be doable in a few nights work, not multi-weeks features.
Here's my discussion about the topic with http://up-for-grabs.net site authors few weeks ago: https://twitter.com/dahlbyk/status/837861619661213697

Our 'simple' label is meant for newbies. I think it has value too. It would be nice to get it into the http://up-for-grabs.net site as secondary query (updated my top post with that idea - I thought about it earlier, just forgot to write it down).

It's quite possible that CoreCLR repo doesn't fully comply with the triage rules we enforced on CoreFX repo.

[jkotas]

Well, the current state in corefx is that folks are marking close to everything with up for grabs without thinking about it and so it does not serve its intended purpose. It is more or less duplicating that the issue is not assigned to somebody yet. Take a look at the current result of https://github.com/dotnet/corefx/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3A%22up%20for%20grabs%22%20 query (ie it is what you get when you click on the corefx link from http://up-for-grabs.net/):

• 1st and 2nd are in .NET Native for UWP. You need access to the closed source compiler to do something about it.
• 3rd one is design discussion about an API needed by PowerShell that is actively being hammered on by involved parties. Nothing to grab there.
• 6th one is a intermittent test failure that happened exactly once in CI. Not very actionable - crashes like this typically sit there for a while and then get closed as no repro.

So 4 out of first 6 are not what I would call good up-for-grabs. If you go through the list, you can find things "Port System.Runtime.Caching to .NET Core" #19691 that's certainly not a few nights project (unless you are Stephen :-).

[karelz]

1, 2 and 6 are likely mistakes (I replied). The guidance I gave to all area teams was "it has to be doable externally (without internal knowledge) and actionable". I even explicitly called out UWP work and CI test failures as bad candidates for up-for-grabs (due to inaccessibility of UWP testing and trickiness involved in CI test failure hunting). I'll be happy to do another round of explanations to area owners, or address those who don't quite follow the rules.
I can also link triage rules to the definition on http://up-for-grabs.net site, that could help as well.

3 is example of special case which I have been thinking about for quite some time -- api-needs-work. I am considering option to unmark all api-needs-work. They are not the best things to grab for someone new to repo who just wants to code.
From another point of view, some API proposals are not rocket science, they are just a bit tricky and have to be thought through ... you need API design experience (something I want to explicitly call out in dotnet/corefx#17534). Also, some API proposals are additions of a couple of methods. So I am a bit torn on this one.

System.Runtime.Caching is example of port-to-core category. Given that it is copy of existing sources from ReferenceSource, I marked it as up-for-grabs. If you think it is a bad judgement of the complexity (few days), we can adjust this particular one. Naively, it feels ok-ish to me (and you know I am not Stephen :P).
In porting exercises, the biggest effort goes into tests. We usually work with community to seed the tests with our internal test assets (SerialPort, SignedXml/EncryptedXml examples).

[jaredpar]

From that perspective, I am not sure if the rename is worth it. Roslyn uses "Up for Grabs", so unless @jaredpar is ok with a change, we won't be consistent across all our core repos anyway.

I'm all for making it simple to jump between dotnet org repos. If we want to pick a standard name here and use it consistently we'd be on board.

[karelz]

OK thanks @jaredpar, I will include Roslyn up-for-grabs rename in this issue as well then.

[karelz]

OK, even more repos are now on board - see the updated list.
I gave CoreFX folks until EOD to push back on the plan. If there's no push back, we can pull it off tomorrow.

[danmoseley]

+1 for "simple"