Re: [poll] Moving all RFCs in a separate repo
@miran: Go for it.
Re: [poll] Moving all RFCs in a separate repo
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.
Re: [poll] Moving all RFCs in a separate repo
/cc @araq @arnetheduck @dom96 @miran| ---|--- We need a decision on this soon, or, if more time is needed, at least lock (see [https://help.github.com/articles/locking-conversations/](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](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.
Re: [poll] Moving all RFCs in a separate repo
+1 and we do need a process to close dead end RFCs. Actually, one counter example actually often enough to kill RFC. Hard truth.
Re: [poll] Moving all RFCs in a separate repo
> +1, but don't transfer issues to the new repo(!). I agree with @dom96 here.
Re: [poll] Moving all RFCs in a separate repo
Python also keeps its PEPs in a separate repository, see [https://www.python.org/dev/peps/pep-0001](https://www.python.org/dev/peps/pep-0001)/ and [https://github.com/python/peps](https://github.com/python/peps). However this repository keeps the POP-documents, these are not issues.
Re: [poll] Moving all RFCs in a separate repo
> 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.
Re: [poll] Moving all RFCs in a separate repo
Use label filters
Re: [poll] Moving all RFCs in a separate repo
@mratsim I don't think we can have two templates in the same repo: one for issues and one for RFC-s.
Re: [poll] Moving all RFCs in a separate repo
I like it for two reasons: * The majority of them are quickly forgotten, it is better to move them out to stop polluting the issues section and give them more visibility in a different place. * I think they are fundamentally different from an issue. When something brokes on my code, I go to the issues tab to see if someone reported the bug already and if there is some workaround, I'm not expecting to find suggestions, questions, RFCs.
Re: [poll] Moving all RFCs in a separate repo
-1 if it stays the way it is (it really messed up my Github profile, as I later realized), but I'm not against rfcs repo per se.| ---|--- 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.
Re: [poll] Moving all RFCs in a separate repo
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?
Re: [poll] Moving all RFCs in a separate repo
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.
Re: [poll] Moving all RFCs in a separate repo
-1| ---|--- Don't introduce unnecessary bureaucracy, just use labels and filters. Random idea: add label "random idea".
Re: [poll] Moving all RFCs in a separate repo
+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.
Re: [poll] Moving all RFCs in a separate repo
+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: * ask the author to expand/formalize the RFC and repost it * or directly close it only if it's no longer relevant
Re: [poll] Moving all RFCs in a separate repo
+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: * **There is less room for ambiguity in the proposals.** This will make it easier to implement RFCs without having to go through yet even more discussions about what an RFC is really about. * **RFCs are only written for proposals which are important enough to warrant time spent writing the RFC**. This should increase their quality and make it more likely that they will be implemented. So please, just close the RFC issues and ask people to write a formal RFC if they are really passionate about their proposal.
Re: [poll] Moving all RFCs in a separate repo
-1, I think in the main repo they get more attention.|
Re: [poll] Moving all RFCs in a separate repo
I posted this issue at the same time, thx for pointing out you wrote this post; here's my full rebuttal with argumentation: [https://github.com/nim-lang/Nim/issues/9378](https://github.com/nim-lang/Nim/issues/9378) rfcs repo is a bad idea
[poll] Moving all RFCs in a separate repo
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](https://github.com/nim-lang/rfcs). There are several pros and cons of this approach: * pros * we now have a repo for all the proposals in one place — both past and future ones * the original issues are linked and easily reachable * all the existing comments are here * all the labels are preserved * cons * the existing reactions (up- and down-votes) are missing * i'm the author of all the previous issues and comments (but every issue and comment clearly states the original author) * the original authors cannot modify "my" issues (this can be remedied by writing a new comment or opening a new issue, which can then close the existing/transferred one) 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.
