└── README.md


/README.md:
--------------------------------------------------------------------------------
 1 | # UnJS Governance Guide
 2 | 
 3 | ## Overview
 4 | 
 5 | UnJS is a collection of independent JavaScript libraries, tools, and utilities.
 6 | 
 7 | Each project is usually made for a specific purpose in the ecosystem following the [Unix Philosophy](http://www.catb.org/~esr/writings/taoup/html/ch01s06.html) and maintained by its author and designated maintainers.
 8 | 
 9 | ## UnJS Goals
10 | 
11 |  - **High-quality and single-purpose** javascript utilities
12 |  - **Healthy ecosystem** with well-maintained repositories
13 |  - **Recognized and trustable** collection of solutions
14 |  - **Collaborative and welcoming** ecosystem
15 |  - **Consistency and compatibility** across the ecosystem with projects that work in harmony
16 |  - **Independent** development of solutions that benefit the majority of JS ecosystem
17 | 
18 | ## Roles and Responsibilities
19 | 
20 | ### UnJS Lead
21 | 
22 | Pooya Parsa ([pi0](http://github.com/pi0)), as the lead and creator of UnJS, is responsible to oversee the organization-wide decisions for introducing packages to be hosted (or to be removed) in UnJS collection and decisions that affect the UnJS identity and vision.
23 | 
24 | The lead ensures UnJS ecosystem remains healthy towards it's goals in collabration with maintainers and team members.
25 | 
26 | ### Maintainers
27 | 
28 | The author and original creator(s) of each project, have the code-owner role defined in the LICENSE file.
29 | 
30 | Code-owner is responsible to:
31 | 
32 | - Define and develop the project's vision
33 | - Make final decisions about the project
34 | - Perform releases and official announcements
35 | - Make official statements in issues and pull-requests
36 | - Assign new maintainers
37 | 
38 | We respect the freedom of each author within their project(s). They have the last word in making decisions and choosing tooling, contributors and code conventions, and their project's roadmap as long as being consistant with overall UnJS vision.
39 | 
40 | In addition to the original author (code-owner), when an individual shows interest to help to maintain and develop a project, they will be granted as maintainer to be directly involved in the project. A **list of all authors and maintainers shall be visible in the repository**.
41 | 
42 | Maintainers are responsible for:
43 | 
44 | - Directly approve and merge pull-requests
45 | - Make official statements in issues and pull requests of the project
46 | - Communicate with the maintainers and the community about the project
47 | 
48 | ### UnJS Team
49 | 
50 | UnJS's ultimate goal is to be a welcoming and collaborative ecosystem. To achieve this, in addition to project maintainers, we invite community individuals to the team to directly help with the triage and maintenance of projects when they do a certain amount of contribution across the ecosystem.
51 | 
52 | Team members can:
53 | 
54 | - Be well-recognized as an UnJS member
55 | - Directly make branches without the need to fork repositories
56 | - Triage and close issues and help the community
57 | - Improve documentations and main website
58 | - Directly be involved in organization-wide discussions
59 | 
60 | Team members in general cannot:
61 | 
62 | - Make official statements on issues in repos they are not maintainer of
63 | - Requesting changes or approving other's pull-requests
64 | - Merge pull requests (docs are the exception and allowed all across)
65 | - Claim credits from other's projects
66 | 
67 | ## Shared Tooling and Conventions
68 | 
69 | To maintain a consistent and compatible ecosystem, UnJS needs templates, shared tools, and guidelines.
70 | 
71 | These tools and templates are not forced to be used as-is but recommended and all members are encouraged to be involved in making suggestions and improving them.
72 | 
73 | ## Communication
74 | 
75 | Hosted projects, as long as being hosted, have the right to use the main website and social media channels to promote and communicate with the community. Team members are involved in the communication process.
76 | 
77 | ## Changes to this Document
78 | 
79 | Changes to this document should be signed-of by the lead before being applied.
80 | 
81 | In case of non-resolvable disagreements with new terms, project owners will be given chance to move their projects out of the organization.
82 | 


--------------------------------------------------------------------------------