separate repo for RFCs

[timotheecour]

/cc @Araq @dom96 @narimiran @krux02

Arguments for separate RFC repo:

• reduces the number of github issues by removing RFC's, so it only contains actual bugs
• rfc issues are not in my face when I look at github issues
• RFC's are all in 1 place

discussion

• https://github.com/nim-lang/Nim/issues shows a total of (1414 open/4221 closed) issues, of which (88 open, 85 closed) are RFC's (via https://github.com/nim-lang/Nim/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Arfc) so the number of issues moved to RFC is only 3 percent of total, ie a negligible cleanup

• "so it only contains actual bugs" is not practical: it's often a gray area whether an issue is: a bug, feature request, or RFC; it could be a bit of all (that's why we have labels, not hierarchies), or can be re-classified overtime

• "rfc issues are not in my face when I look at github issues"
  this is bogus: just use negative label filter "is:issue is:open -label:rfc" (which github introduced back in 2014)
  https://github.com/nim-lang/Nim/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Arfc+
  this will filter out from your view all RFC's

• RFC's are all in 1 place
  this is bogus for same reason: just use a positive filter https://github.com/issues?utf8=%E2%9C%93&q=label%3Arfc+

further arguments against separate RFC repo

moving existing RFC issues to https://github.com/nim-lang/rfcs/issues causes all existing links to be broken, eg:

• a git commit msg #123 or nim-lang/Nim/#123 or full URL
• likewise with links in source code (including in other repos pointing to nim-lang), or in people's personal notes
• all votes are gone
• all messages are shown as @narimiran ; this makes it impossible to find RFC's your authored or search for comments by @someone using the github UI or API (and searching for the name in the body has other issues)
• once some issue is re-classified as RFC, we'd have to close it and copy it to a separate repo: this doens't make sense.
• with a separate repo, when searching for a label (eg: "Parser"), you'd now need to search in 2 different repos (rfcs and Nim) instead of 1
• **now original author can't modify his own RFC or change the title ** (note: good practice for edits is to use EDIT or [EDIT] to avoid confusion) unless he re-creates a new issue, causing more mess (eg loosing comments, votes etc) in the process

Labels are good, use them. Hierarchies (nim-lang/Nim ; nim-lang/rfs) are good for some things, but not for that.

Note: you can use your favorite bookmark mechanism to access issues using customized filters with 1 click (eg in chrome I use bookmark bar)

for example : https://github.com/issues?utf8=%E2%9C%93&q=is%3Aissue+author%3Atimotheecour+sort%3Aupdated-desc+ for easy access

[narimiran]

Let's keep it in one place: https://forum.nim-lang.org/t/4315

[dom96]

Discussions like this belong on the forum. Closing this.

[timotheecour]

(renamed to avoid making this issue show up in google in 2nd position when searching for nim RFCS, now that it's accepted)

[Araq]

Now that we have the RFCs over there we might as well keep them there, right? :-)