This document is not in its final version, **a team meeting which aims to address new/old best practices, feedback, workflows, all kind of issues related to how the team works together occurs every 2 weeks.**
This document link to other specialized best practices (like coding best practices).
- Daily standup (1pm CET - 11am GMT) for taking care of the current issues.
- A regular standup - each Tuesday (3pm CET - 1pm GMT) - which aim to
- Update every contributor on what others are doing.
- Update the prioritised issues / PRs list.
- Address little issues (possibly related to the current ongoing milestone).
- High level demo, explanation about specific points of the codebase or Ethereum related things.
- A milestone standup - scheduled before the beginning of each milestone, roughly on a monthly basis - which aim to define what will be included in the **next milestone** and who will work on what. This standup also help to set a clear long term vision.
- A retrospective standup - after each release - which aims to talk about **best practices in general**: what is good, what is bad, how we can improve workflows.
- A tour standup - Just after a release or whenever it is needed - which aim to demo, **explain in details** features, bug fixes or any part of the codebase.
- When a story / bug fix is divided in parts, there should be a kickstart meeting with all the developers involved, so that all the devs have a good overview / understanding on:
- Later progress and discussion is updated directly on the issue or pull request (github).
- When a developer or team decides on the story they want to work on (at the start of milestone for instance), they assign themselves to the issue.
- Documentation update should be done together with the story, or an issue with the label "documentation" has to be created.
---
# Pull Requests
### 1) PR Creator:
- It is recommended to use the emoji responses to signal agreement or that you've seen a comment and will address it rather than replying. This reduces github inbox spam.
- Mark unfinished pull requests with the `Work in Progress` label
- Large pull requests (above 200-400 lines of code changed) cannot be effectively reviewed and should be split into smaller pieces.
- Code should comply to the `JavaScript standard style` - https://www.npmjs.com/package/standard
- You should not expect complete review on a pull request which is not passing CI.
- You can obviously ask for feedback on your approach.
- You should assign a reviewer(s).
- Pull requests should be used as a reference to update coding best practices whenever it is needed.
### 2) Review:
- Everyone is free to review any pull request.
- You should add the label "change requested" or "accepted".
- When reviewing people's code consider the following two comments.
> I don't like the name of this function.
vs.
> What do you think about changing the name of this function to ....
Your feedback will often be better received if you pose it in the form of a question.
- Pull request should be reviewed to comply to coding best practices.
- We can release an `m.m.m-alpha.x` (whenever we need to release and for whatever reasons) being in between a feature / bug fix completion.
- We release an `m.m.x` whenever there is a bug fix.
- We release an `m.x.0` whenever there is a new feature.
- We release an `x.0.0` after each milestone we consider being an important progress.
- We release an `x.0.0` if there's an API breaking change in one of our libraries.
- After a new release we should stay in alert for possible regression and better not release Friday at 5pm :)
### 2) Community:
- Before the official release, we should select a group of power users and invite them to test and give feedbacks.
- Users need to know upfront a new release is coming and we should prepare them for it by showcasing some new features they can expect and when it will happen (fixed date, published at least 1 week in advance).
- Whenever we have a new release we have to communicate this efficiently (twitter, reddit, ...).
---
# Maintenance
### 1) Bugs:
- A critical bug should get the label `Blocker`, and every effort should be put to fix it.
- Addressing a non critical and non planned bug can be done:
