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 work together occurs every 2 weeks.**
- A milestone standup - scheduled before the beginning of each milestone, roughly on a monthly basis - which aims 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 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 aims 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:
- 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.
- Progress and issues regarding a milestone are discussed on regular standups.
---
# 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, ...).
- Find a good calendar we can use to schedule meetings.
- Retrospective meeting: Someone can be responsible to record the findings (of the retrospective meeting) so we can review them in the following meeting and see if they were addressed or not, and if not discuss why and take new actions. If the issue was addressed then it can be discarded.
- pair programming meetings
### merge process:
- All the contributors of the feature should be able to merge.
- Review should have 3 phases (1. code should work, 2. code should fit with current best practices, 3. update documentation)
- We should have a dedicated person to only do browser frontend tests and make it easy for others to run them
### release process:
- We release an `x.0.0` if there's a fundamental change in our UX design, which means users will need to readapt the way they use the app
- after a week finishes, we publish/release a new version as **remix-beta.ethereum.org** and inform users so early adopters can test. after another week, when the next finished work is released as **remix-beta.ethereum.org**, the previous one becomes **remix.ethereum.org** and all users can start using it
- a bot to automatically notify users about upcoming features on all channels whenever **remix-beta.ethereum.org** is updated
- in case it's a major version increase - this announcement should be specially marked so ppl can check early instead of being confronted with drastic changes when **remix.ethereum.org** updates
### maintenance:
- Setting up a "bug" time where we each take a bug for which:
- We set up a special day where we address all the necessary documentation work in a team effort.
- Change to markdown or gitbook
### support:
- Remix channel - we rotate and each day one or two are responsible for support (It would also be important to know for those of us who are contracted, how this can be billed.). If they don't know the answer they ping team member who they think could answer. That team member checks the support chat that day only if she/he is mentioned.
- People should be pointed to the appropriate `best practice.md` files by team members
### code best practices:
- for code quality: use codeclimate and address issues
- defining all global variables on top of the page
- 80-10 characters per line
- alphabetically list dependencies and separate npm from local for better readability
- Use code documentation tool
- Write modular code.
### community
- This should be a Remix team work, from time to time (maybe once every 6 months) we could also invite other EF members for a focus group. And every 6 months we could also organize a focus group of selected users from Remix channel.
