Comments (11)
Sadly accept that the gh-pages URL will never redirect
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".
from proposals.
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...
from proposals.
Hi @domenic , given especially the responses from @allenwb and @bterlson , unless you object, I'm going to proceed assuming stage 1 and close this bug. If you do object, please reopen. Thanks.
from proposals.
Stage 1 is the ideal, IIRC.
from proposals.
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.
from proposals.
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.
from proposals.
- Transfer the repo to @bterlson
- @bterlson bounces it into the tc39 org
- Never create your own fork (or same-named repo) again, or else the repo redirect will break
- Sadly accept that the gh-pages URL will never redirect
from proposals.
I'm pretty sure we've had consensus before that stage 1 (prior to stage 2) is when the repo should be transferred.
from proposals.
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 proposals.
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?
from proposals.
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.
from proposals.
Related Issues (20)
- please link to the right place to submit proposals in the placeholder text HOT 1
- Please create Stage 1 float16 repo HOT 4
- Any way to get a date from a locale date string? HOT 1
- link of proposal-async-await is outdated HOT 2
- Permissions for proposal-canonical-tz repo HOT 2
- Stage 1 proposals should be included in the README HOT 20
- Data Structures and Algorithms HOT 5
- [spam]
- [spam]
- [spam]
- [spam]
- [spam]
- [spam]
- [spam]
- [spam]
- feature request: include entire notes history with proposals HOT 17
- Intl.DurationFormat last presented date is inaccurate
- [spam]
- inactive proposals missing presented links HOT 1
- proposal-uuid is no longer active
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from proposals.