-
Notifications
You must be signed in to change notification settings - Fork 720
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When should proposals migrate to a tc39 github repository? #44
Comments
Stage 1 is the ideal, IIRC. |
I would support making this a stage 1 entrance criterion for what it's worth. There has been some pushback in the past as moving the repo is work. |
I've been confused about the process myself. Perhaps a step-by-step explanation of how to do it would help? I know it would help me. |
I'm pretty sure we've had consensus before that stage 1 (prior to stage 2) is when the repo should be transferred. |
This can be slightly mitigated. https://gist.github.com/domenic/1f286d415559b56d725bee51a62c24a7 Overall I would prefer stage 2 as things shouldn't be branded tc39 unless "the committee expects the feature to be developed and eventually included in the standard". |
I'd be fine with it being part of the transition to stage 2 (i.e., immediately after the meeting where it becomes stage 2). Thanks, that's a great tip about the gh-pages problem! |
From a purely standards governance perspective, we are technically required (I believe) to even create the repository on TC39's org and never have it external. In other words, the work that we do for stage 0 and 1 proposals that don't advance further are still proposals whose work should be officially tracked, archived, and whatever. I am fine compromising this in order to have a reasonable process, but I'm not sure that the difference between stage 1 and 2 is that large so might as well get the pain overwith earlier in the process... |
Like @bterlson says. Anything that is formally presented to TC39 is a "contribution" and is supposed to be captured as part of the Ecma TC39 archives. So should discussions of a contribution such as might take place via github issue threads. The reason is that Ecma is supposed to be keeping a record of where ideas came from and how they were developed for the standard, just in case there are future concerns or disputes. For stage 0 presentations, it is probably sufficient to capture a snapshot of a presentation deck in the meeting notes repository (alternatively, it can be formally submitted to the Ecma Secretariat as a contribution). Beyond that, I think all materials should definitely be hosted on the TC39 site. There seems like a situation where it is better to be a hoarder rather than taking the risk of loosing something that in the future you discover you need. What's the problem with aggressively migrate materials to TC39? |
FWIW when the repository transfers, all of its issues and comments and such history goes along with it. So a post-hoc transfer of stage 1/2 proposal would still contain all the history. My biggest worry is for proposals that are rejected, withdrawn, or abandoned prior to stage 2. For that reason I'd lean toward a stage 1 entrance criterion. |
Many of the links at https://github.com/tc39/proposals are to personal repositories. Some of these already redirect to a tc39 repository but many do not, including a stage 2 proposal. When should proposals migrate to a tc39 repository? Does the process document or any other document say?
The text was updated successfully, but these errors were encountered: