Skip to content
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.

Sign up for GitHub

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

Jump to bottom

CreateJS Community Mission #4

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

CreateJS Community Mission #4

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0593a39
WIP consortium first draft
jedateach Mar 13, 2020
82849c8
Update Consortium.md
jedateach Apr 1, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 51 additions & 0 deletions Consortium.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@
# CreateJS Consortium
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't in the proper format - content needs to be moved into the file below.


The GSkinner team is handing the CreateJS project over to the community.
Copy link

@danzen danzen Mar 13, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps: "The GSkinner team is encouraging the community to get involved in in the maintenance and direction of CreateJS."

I am not sure they are ready to give it up completely. Probably a side-by-side approach may be the way to look at it. So the title - "Start a consortium to take over CreateJS" may be a bit dramatic - although it does sound like what consortia do! How about "Inititial Proposal to help maintain CreateJS".

From a meta standpoint... can we edit this document directly anywhere? Or do we just provide comments? Also... what is the "Start a review" button and when would we use it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I had made some assumptions about what was happening. Happy to reword.

To edit, you can certainly submit a PR to merge into my PR branch on my jedateach github. I might somehow be able to give you permission to edit my branch directly from this ui.


A plan needs to be made clear to give confidence that this is a wise decision.

This document describes actions that need to be taken in order for confidence to be had in the community-driven effort.

## Vision

> What is is this project's vision?

## Project Principles

* *Let humans and machines each do what they are good at*. For example, humans can make high level design decisions, and machines can build and release a version of the project.
* Protect stability, performance

## Community

Anyone can submit a pull request for a change.
PRs are automatically checked via automated build, and bots.

## Core team

The core team are trusted to represent the interests of the whole.

Only they can merge PRs, and approve high-level decisions.

Responsible community members will agree to uphold the chosen standards of the project.

They will be responsible for reviewing and approving code changes, ensuring they take adequate time to understand the change.

They uphold the project code of conduct.

### Core team onboarding


## Practices

* Test coverage can only ever increase.
* Peer review of code - approved by 2 or more core developers, other than the submitter.
* Follow semantic versioning.
* Provide backwards compatibility for as long as possible. Deprecate code, and pull it out only when major version change (such as 2.x.x -> 3.0.0)

* Stale bot to close issues if contributor is being waited on

## Questions

Answer these questions, as checklist items above.

* How do we ensure change log is always updated?
69 changes: 69 additions & 0 deletions text/0000-consortium.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
- 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, ...)

# CreateJS Consortium
Copy link
Contributor Author

@jedateach jedateach Mar 13, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is consortium even the right name? I'm happy to run with it for now, but I'm not certain we'd need to refer to it this way once decided how we do stuff.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is Webster's definition:

Consortium: an agreement, combination, or group (as of companies) formed to undertake an enterprise beyond the resources of any one member. E.g. A consortium of researchers decoded the honeybee genome.

Sounds friendly in that example... but usually it sounds business-like and might get confused with a Cartel, etc. Anyway - it has alliteration CreateJS Consortium. Its definition fits. It sounds official and it holds weight. But... is it cool? Is it nerdy enough? It is not as fun as CreateJS Crew... etc. Maybe all the consortium does is put together the plan and that includes a name for the future!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not that I'm that bothered by it, just giving my 2c: I've not heard 'Consortium' used on open source projects. Off the top of my head, there's usually a community, and some kind of core leadership. In my opinion is that there's great benefit in helping the community getting involved. This means removing barriers to contribution from a range of expertise levels. This might mean defining what can be done, how to do it, and how it will be lead/managed/guided/moderated etc by the core team.

Is the core team the consortium?

Anyway - again, I'm not too fussed by naming.


## Summary

Set up a consortium process/team to run the CreateJS project.

## Motivation

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:
https://github.com/CreateJS/EaselJS/issues/1040

## Detailed design

> 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.

### Mission statement

> What is is this project's mission statement

> https://producingoss.com/en/getting-started.html#mission-statement

## How we teach this

> 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?

## Drawbacks

> 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.

## Alternatives

> 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.

## Unresolved questions

> Optional, but suggested for first drafts. What parts of the design are still
TBD?

## Research

https://producingoss.com
https://guides.github.com
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's quite a few things in these to consider. I think everyone interested in becoming a core member should have a read.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can draw out important aspects, and codify them in this RFC.