Council Member Responsibilities
There are 3 distinct areas of responsibility: designing, implementation, and management.
Preface - Terms
Repositories - Place where code & models are stored (e.g. GitHub)
Task - A piece of implementation work (i.e. coding a piece of a feature or making a model)
Design and Implementation boards - the two GitHub project boards (+ the model trello list)
Wiki - Where all documents are put. Not quite sure exactly where that is right now.
Chat - The official place where communication takes place, in our case the Discord server.
Responsibility - Designing
The team must collectively agree upon the features of the game before they can be implemented. Additionally, community opinion must be considered during design, and designed features must be publicly viewable.
- An idea is placed into the design board's backlog, prioritised
- The most prioritised idea is put into in-design. A wiki document is made for it where members of the team start writing up the design.
- Team members should not erase text without general agreement
- Documents should be in-design at least long enough for most of the team to contribute
- Controversial pieces should be open for community involvement and discussion, so that they can influence the outcome. This could be done by vote or announcement on Chat.
- Once the document is complete it is put into review, where any final problems are discussed
- Any still existing problems can be mentioned in the wiki document, in a seperate section
- (optional) the community can vote (in Chat) on whether to accept the feature
- The review finishes when a majority passes the design.
Permissions & Tooling
The dev board must have columns for backlog, in design, in review, and complete. The wiki must have a section for writing feature designs. The chat must have a way for team members to create votes and announcements, and team members must be able to read and respond to community voices in the chat.
All team members have permission to read and modify the board and the wiki. The public has permission to read the board and wiki.
Responsibility - Implementation
The team maintains the quality of the model and code repositories, and maintains the boards that track what work is available, in progress, and complete. Additionally, team members can assign people to work on specific tasks.
Unlike designing, this responsibility is more individual - collective agreement is not required for many of the tasks.
- Team members (somewhat collectively) take designed features and turn them into tasks in the backlog
- Team members (somewhat collectively) prioritise tasks in the 'backlog' and 'available' columns
- Available tasks are ones people can work on, backlog need to be done but aren't meant to be worked on yet.
- Team members decide when to move the (top prioritised) tasks from 'backlog' to 'available'.
- Tasks could be moved to ensure the available column has X amount of work in it.
- Any team member can assign an available task to anyone, and move the task to in-progress
- Any team member can review a task that has been completed.
Permissions & Tooling
The implementation boards should indicate what tasks are available and unavailable to work on, in progress (and who is assigned to them), being reviewed, and what tasks are complete. Tasks that fail their review go back to being in-progress, tasks that pass their review should be immediately be placed in their respective repository. With GitHub, a lot of the above steps can be automated (e.g. accepted reviews being placed in the Done column). Additionally GitHub can require PRs for tasks before merging.
Team members have permission to modify the boards, and review (and merge) PRs to the repositories, as well as all public permissions. The public has permission to read the board and repositories, request to be assigned tasks, and submit PRs (for tasks they are assigned to).
Responsibility - Management
The team chooses collectively who is on the team. There can be some rules relating to promotion/demotion that are generally agreed on.
- When choosing to promote someone, enough time must be given for team members to voice opinions
- Same goes for demoting
- There could be automatic demotion for inactive members, e.g. 2 months of no development and/or 1 month of inactivity in chat. If they start contributing again they could be promoted again (i.e. its a demotion without prejudice)