if(process.platform==='win32'&&err.message.includes('3221225781'))returndispatch({type:'SET_COMPILER_FEEDBACK',payload:'The compiler failed to start because of some missing dependencies. Please install or repair the Microsoft Visual C++ Redistributable package to resolve this issue.'})
Before starting coding, we should ensure all devs / contributors are aware of:
Before starting to coding, we should ensure all devs / contributors are aware of:
- Where the codebase is.
- Where the codebase is.
- How to setup and get started (always up to date).
- How to setup and get started (always up to date).
- How to run tests.
- How to run tests.
@ -87,7 +87,7 @@ Before starting coding, we should ensure all devs / contributors are aware of:
- Mark unfinished pull requests with the `Work in Progress` label
- 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.
- 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
- 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 should not expect a complete review on a pull request which is not passing CI.
- You can obviously ask for feedback on your approach.
- You can obviously ask for feedback on your approach.
- You should assign a reviewer(s).
- You should assign a reviewer(s).
- Pull requests should be used as a reference to update coding best practices whenever it is needed.
- Pull requests should be used as a reference to update coding best practices whenever it is needed.
@ -109,7 +109,7 @@ Before starting coding, we should ensure all devs / contributors are aware of:
- You should take the responsibility of the PR you are reviewing.
- You should take the responsibility 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 app is viable after the PR is being merged.
- You should make sure the PR is correctly tested (e2e tests, unit tests)
- 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.
- Ideally you should have enough knowledge to be able to fix related bugs.
### 3) Merge:
### 3) Merge:
@ -143,7 +143,7 @@ Before starting coding, we should ensure all devs / contributors are aware of:
- We release an `m.x.0` whenever there is a new feature.
- 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` 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.
- 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 :)
- After a new release we should stay in alert for possible regression and better not release on Friday at 5pm :)
### 2) Community:
### 2) Community:
- Before the official release, we should select a group of power users and invite them to test and give feedbacks.
- Before the official release, we should select a group of power users and invite them to test and give feedbacks.
@ -197,7 +197,7 @@ Before starting coding, we should ensure all devs / contributors are aware of:
- 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
- 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
- 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
- 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
- in case it's a major version increase - this announcement should be specially marked so people can check early instead of being confronted with drastic changes when **remix.ethereum.org** updates
### maintenance:
### maintenance:
- Setting up a "bug" time where we each take a bug for which:
- Setting up a "bug" time where we each take a bug for which: