docs/help/Development-Process.md

   1 * [Proposals, Get Answers and Report a Bug via Github Issues](#proposals-get-answers-and-report-a-bug-via-github-issues)
   2 * [Feature development process](#feature-development-process)
   3 * [Approval Path for PR(Pull Request)](#approval-path-for-prpull-request)
   4 * [Tips on GitHub Issues](#tips-on-github-issues)
   5
   6 ***
   7
   8 It is the responsibility of IoT.js Maintainers and Reviewers to decide whether submitted code should be integrated into the master branch, returned for revision, or rejected.
   9
  10 Individual developers maintain a local copy of the IoT.js codebase using the git revision control system. Git ensures that all participants are working with a common and up-to-date code base at all times. Each developer works to develop, debug, build, and validate their own code against the current codebase, so that when the time comes to integrate into the master branch of the project, their changes apply cleanly and with a minimum amount of merging effort.
  11
  12 ### Proposals, Get Answers and Report a Bug via Github Issues
  13
  14 If you have a question about IoT.js code, have trouble any documentation, would like to suggest new feature, or find a bug, [review the current IoT.js issues](https://github.com/Samsung/iotjs/issues) in GitHub, and if necessary, [create a new issue](https://github.com/Samsung/iotjs/issues/new).
  15
  16 **There are several labels on the Issue. Please choose proper labels on the purpose.**
  17 * **bug**
  18 * **community** : any issues on the community operation
  19 * **enhancement** : feature enhancement proposal
  20 * **help wanted**
  21 * **new feature request(proposal)** : new feature proposal
  22 * **project announcement** : general announcement on the project such as new release, new Maintainer/Reviewer and so on
  23 * **question** : any questions on the project
  24
  25 and so on.
  26
  27 ### Feature development process
  28
  29 The IoT.js Project development process is marked by the following highlights:
  30 * The feature development process starts with an author discussing a proposed feature with the Maintainers and Reviewers
  31   - Open the issue with label 'new feature request(proposal)'
  32 * The Maintainers and Reviewers evaluate the idea, give feedback, and finally approve or reject the proposal.
  33 * The author shares the proposal with the community via **_Github issues with 'new feature request' label_**
  34 * The community provides feedback which can be used by the author to modify their proposal and share it with the community again.
  35 * The above steps are repeated until the community reaches a consensus according to the [Community Guidelines](Community-Guidelines.md).
  36 * After a consensus is reached, the author proceeds with the implementation and testing of the feature.
  37 * After the author is confident their code is ready for integration:
  38   - The author generates a patch and signs off on their code.
  39   - The author submits a patch according to the [Patch Submission Process](Patch-Submission-Process.md).
  40 * The Maintainers and Reviewers watch the pull request for the patch, test the code, and accept or reject the patch accordingly.
  41 * After the code passes code review, the Maintainers and Reviewers accept the code(integrated into the master branch), which completes the development process.
  42 * After a patch has been accepted, it remains the authoring developer's responsibility to maintain the code throughout its lifecycle, and to provide security and feature updates as needed.
  43
  44 ### Approval Path for PR(Pull Request)
  45 1. Developer should create/update PR to a given issue or enhancement
  46 2. If Developer works in a team, then peer-review by a colleague developer should be performed
  47 3. If peer-review was OK, then Developer should summon the component's maintainer
  48 4. Maintainer should check the code:
  49    - make precommit testing is OK (performed automatically)
  50    - No minor issues (unified implementation style, comments, etc.)
  51    - No major issues (memory leak, crashes, breakage of ECMA logic, etc.)
  52 5. If Developer has to rework the solution then goto step 3
  53 6. If everything is OK, then Maintainer should approve the PR with +1(or LGTM)
  54    - Code review can be performed by all the members of the project. However only Maintainer can give binding scores.
  55 7. When the PR get +2(2 LGTM from 2 mainatiners respectively), it should be merged.
  56
  57 ### Tips on GitHub Issues
  58
  59 * Check existing [IoT.js issues](https://github.com/Samsung/iotjs/issues) for the answer to your issue.
  60 Duplicating an issue slows you and others. Search through open and closed issues to see if the problem you are running into has already been addressed.
  61 * If necessary, [open a new issue](https://github.com/Samsung/iotjs/issues/new).
  62   - Clearly describe the issue.
  63      + What did you expect to happen?
  64      + What actually happened instead?
  65      + How can someone else recreate the problem?
  66   - Include system details(such as the hardware, library, and operating system you are using and their versions).
  67   - Paste error output and logs in the issue or in a Gist(https://gist.github.com/).
  68
  69 For more information about GitHub issues, refer to the [GitHub issues guidelines](https://guides.github.com/features/issues/).