- Start Date: (fill me in with today's date, YYYY-MM-DD)
- RFC PR: (after opening the RFC PR, update this with a link to it and update the file name)
- Relevant Project: (e.g. EaselJS, SoundJS, PreloadJS, TweenJS, ...)
Set up a consortium process/team to run the CreateJS project.
The GSkinner team is handing the CreateJS project over to the community. CreateJS will not live unless people actively maintain the project. A plan needs to be made clear to give them confidence that this is a wise decision.
This process was initially started here: CreateJS/EaselJS#1040
This is the bulk of the RFC.
Explain the design in enough detail for somebody familiar with the project to understand, and for somebody familiar with the implementation to implement. This should get into specifics and corner-cases, and include examples of how the feature is used. Any new terminology should be defined here.
What is is this project's mission statement
https://producingoss.com/en/getting-started.html#mission-statement
What names and terminology work best for these concepts and why? How is this idea best presented? As a continuation of existing patterns, or as a wholly new one?
Would the acceptance of this proposal mean the CreateJS guides must be re-organized or altered? Does it change how CreateJS is taught to new users at any level?
How should this feature be introduced and taught to existing users?
Why should we not do this? Please consider the impact on teaching CreateJS, on the integration of this feature with other existing and planned features, on the impact of the API churn on existing apps, etc.
There are tradeoffs to choosing any path, please attempt to identify them here.
What other designs have been considered? What is the impact of not doing this?
This section could also include prior art, that is, how other frameworks in the same domain have solved this problem.
Optional, but suggested for first drafts. What parts of the design are still TBD?