
# Team best practices

This document aims to address contibutors best practices of the following repositories:
 - remix-ide https://github.com/ethereum/remix-ide
 - remix https://github.com/ethereum/remix
 - remixd https://github.com/ethereum/remixd

This document is not in its final version, **a team meeting which aim to address new/old best practices, feedback, workflows, all kind of issues related to how the team work together occurs every 2 weeks.**
This document link to other specialised best practices (like coding best practices).

Related links:
 - Public WebSite: https://remix-project.org
 - Awesome Remix: https://github.com/ethereum/awesome-remix
 - Remix basic FAQ: https://hackmd.io/KVooMJhWRImCGq6zkDgW9A
 - Remix live: https://remix.ethereum.org
 - Remix alpha live: https://remix-alpha.ethereum.org
 - Remix beta live: https://remix-beta.ethereum.org
 - Remix-lib NPM module: https://www.npmjs.com/package/@remix-project/remix-lib
 - Remix-tests NPM module: https://www.npmjs.com/package/@remix-project/remix-test
 - Remix-solidity NPM module: https://www.npmjs.com/package/@remix-project/remix-solidity
 - Remix-debug NPM module: https://www.npmjs.com/package/@remix-project/remix-debug
 - Remix-tests NPM module: https://www.npmjs.com/package/@remix-project/remix-tests
 - Remix documentation: http://remix-ide.readthedocs.io/en/latest/
 - General gitter channel: https://gitter.im/ethereum/remix
 - Dev gitter channel: https://gitter.im/ethereum/remix-dev
 - Dev plugin gitter channel: https://gitter.im/ethereum/remix-dev-plugin
 
 
---

# Team communication

 ### 1) Team meetings:
 
 - 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 releases - which aim 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.
 
 
 ### 2) Group meetings:
 
 - 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 an good overview / understanding on:
     - How the story fits into the Ethereum tech.
     - How the backend (if any) works / will work (could be a smart contract).
     - How the frontend works / will work.
     - What is the general vision of the UX design for this particular story.
     Later progress and discussion is updated directly on the issue or pull request (Github).
 
---

# Prerequisites:

Before starting coding, we should ensure all devs / contributors are aware of: 
- Where the codebase is.
- How to setup and get started (always up to date).
- How to run tests.
- Where to find documentation.
- How to reach us through the communication channels - https://gitter.im/ethereum/remix, https://gitter.im/ethereum/remix-dev.
- The following best practices:

---

# Story / Bug fix

- Prioritised list of PRs / issues are tracked in a Github Project, Remix IDE issues are managed by a prioritized backlog.
- Every story can be executed by a single developer or a group of 2 or more developers (depending on the size and complexity)
- Each dev should take the part he/she feels the most confortable with.
- 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.
 - You should take the responsability of the PR you are reviewing.
 - You should make sure the app is viable after the PR is being merged.
 - You should make sure the PR is correctly tested (e2e tests, unit tests)
 - Ideally You should have enough knowledge to be able to fix related bugs.
      
 ### 3) Merge:

 - Merging is possible after Review and Tests are ok and when the PR is approved.
 - After a merge, it is highly recommended to check the new code in `remix-alpha.ethereum.org`

---

# Milestone

 - A milestone should **only** contain items we are sure to finish.
 - The end of a milestone trigger a new release.
 - Milestone items and duration should take in account time spent in bugs fixing and support.
 - The team should commit to the milestone duration.
 - If a dev finish early he/she can help other to push remaining tasks.
 - If a dev finish early he/she can work on specifying / integrating the next milestone.
 - A milestone duration is fixed at the start of the milestone (but should better not exceed 1 month).
 - Progress and issues regarding a milestone are discussed on regular standups.
 

# Milestone - Refinement meeting

 - A meeting is organized 3 weeks after the beggining of a round. This aims to :
   - list what is left to do.
   - identify any blocker.
   - agree on a release date (which can be earlier 1 week after the meeting and not later than 4 weeks after the meeting.
   - add issues that are eligible to get in the release.
   - remove issues that aren't doable in time or represent a risk.
   - plan for asking feedback about new features (in social medias).

---

# Releases
 
 ### 1) Process:
 - Should be documented and updated.
 - A new release is triggered:
    - after an important bug fix
    - at the end of a milestone
 - 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:
  - After having notified in the `remix-dev` channel if the bug does not involves UX or public API changes.
  - After a dev meeting (e.g the regular standup) if the bug involves any UX or public API changes.

### 2) Support:

- We should all keep an eye on the public non dev channel and file user feedback.

### 3) Documentation:

- The documentation is done / updated just after the feature / release in a team effort.
- Documentation work is filable as a github issue.
- It is encouraged to find and link associated doc produced by the community (blog posts, videos, tutorials, ...)

---

# Coding best practices

 - https://github.com/ethereum/remix-ide/blob/master/best-practices.md
