There was an idea by @araq to move all (future) RFC-labeled issues to their own repo. But the problem is: what to do with the current issues? (You cannot just move issues from one repo to another)
Fortunately, we found a script which helps with transferring the existing issues to a new repo. You can see the results of that script in the new rfcs repo.
There are several pros and cons of this approach:
If this idea is accepted, we could close all RFC-labeled issues in the Nim main repo, making it the place to discuss real issues.
The reason why I'm posting this is because @araq asked me to to create a poll for this, to see the reactions.
If you like the proposal, please click 'like' or write "+1", "yay" or something that is clear that you are for this.
If you are against it, please write "-1", "nay", etc. and please explain why and/or offer a better/easier solution.
+1, but don't transfer issues to the new repo(!).
The reason for a separate repo is to increase the barrier to entry for RFCs, we are overwhelmed by the number of RFCs and a lot of them are just random ideas that people come up with and not think through (sorry, but it's the harsh truth). The RFC repo should specify a formal template of how an RFC should be described and everyone should stick to it. This will ensure that:
So please, just close the RFC issues and ask people to write a formal RFC if they are really passionate about their proposal.
+1
I kinda agree with @dom96 , but I don't think we should just forget for the existing RFC-s. Instead I suggest to leave the one-s that are already detailed enough (because their author already did a good job and as an example for new RFC-s) and for the other one-s:
Don't introduce unnecessary bureaucracy, just use labels and filters. Random idea: add label "random idea".
+1 for labels rather than alternate repos (or more labels such as "random idea" or "half-baked" or such).
But, also +1 if Nim core devs want to aggressively close issues that are too incomplete to be a "real" RFC or are considered settled questions.
Looking in only one place is better, and it's better for code linking as well so -1.
However more aggressive closing and a Github template that should basically tell:
RFCs (Request for Comments/Changes)
We welcome Nim enhancement proposals, while there is no minimum please ensure that the current context, how you see your proposal improves it and an expected transition if it's not backward compatible are documented. Here are some examples of RFCs 1, 2, and 3 that though different, illustrates what kind of proposals we are looking for. We might close your proposal until further rework, for that we're sorry, don't take it to heart we do welcome contributions, as the language is growing we are learning as well on how to manage our time.
We might as well through an issue template as well
Issues
We will not ask you to fill a dreaded form before reporting an issue. However it is crucial that we get steps to reproduce your issue. The best would be a minimal test that only uses Nim and the standard library. This way we can integrate it to Nim test suite and ensures that no regressions occur in the future.
Ok, I have switched my vote from that on IRC. It's a -1 from me too:
Looking in only one place is better, and it's better for code linking as well so -1.
This is really useful.
As for low barrier for entry for RFCs, may be just be quick to pull trigger on closing bad/incomplete RFCs?
I agree with the comments that we should review the existing proposals and close the ones that do not satisfy some minimal criteria or are not relevant any more. (Not just close everything)
I really like the idea of templates, both for RFCs and for issues.
I don't think we can have two templates in the same repo: one for issues and one for RFC-s.
I've checked and it allows me to make multiple templates. So this shouldn't be a problem.
+1, but don't transfer issues to the new repo(!).
I agree with @dom96 here.
We need a decision on this soon, or, if more time is needed, at least lock (see https://help.github.com/articles/locking-conversations/) in the meantime the duplicated exported issues opened in rfcs, as people are starting to comment on these, eg: https://github.com/nim-lang/rfcs/issues/65#issuecomment-430765386 instead of on the original RFC's in Nim Repo, and we'll soon end up with info that's spread across several places.
If that's ok with the others, I would like to delete the rfcs repo, since that is the only way to delete "my" 88 issues (these have ruined my Github profile/dashboard).
After that, we can open a new, clean, rfcs repo.