neo icon indicating copy to clipboard operation
neo copied to clipboard

NEO Core Developer Work Guidelines (Draft)

Open Jim8y opened this issue 1 year ago • 40 comments

this is from @lock9, i think he presents the guideline better than me.

Development Process Guidelines

  1. Voluntary Issue Assignment:

    • Core developers may voluntarily take on new issues.
    • They must comment on the issue to claim it.
    • If multiple developers are interested in the same issue, priority goes to the developer who created the issue, followed by the solution proposer.
  2. Issue Discussion Before PR:

    • Core developers should thoroughly discuss their proposed solution on the issue thread before starting work.
    • The team must approve the issue before proceeding to PR.
    • An issue must be closed with a reason (@roman-khimov).
  3. Descriptive PR Submissions:

    • PRs (Pull Requests) should clearly outline the problem and the proposed solution.
  4. Solution Voting on Disagreements:

    • All core developers will vote in cases of differing solutions for the same problem.
    • A simple majority decides the approach.
    • Any core dev can call a vote on a decision.
    • Voting must happen within 21 days.
    • The PR submission follows the chosen solution.
  5. Voting on Self-Submitted Issues:

    • Core developers can work on PRs for their own submitted issues.
    • These issues must be approved by a core developer vote.
  6. Comprehensive Comments and Updates:

    • Submitted code should include inline comments and unit tests.
    • PRs must not decrease overall code coverage.
  7. Reporting Breaking Changes:

    • Changes affecting other SDKs or Neo's general behavior must be communicated.
    • Developers should provide necessary update instructions.
  8. Draft Mode for PRs:

    • PRs should be marked as draft until they are ready for merge.
    • Ready-for-merge PRs require voluntary reviews from multiple core developers.
  9. Timely PR Reviews:

    • If a PR lacks sufficient reviews within one month, it will be considered stalled.
    • Stalled PRs are considered incidents and will require action from the team.

bellow is the old version.

NEO Core Developer Work Guidelines

  1. Voluntarily Taking on Issues:

When new issues arise, core developers can voluntarily take on the task of resolving them.

  1. Issue Discussion Before PR:

Before submitting a pull request (PR), core developers must describe their proposed solutions in detail within the issue thread.

  1. Descriptive PR Submissions:

PRs must clearly describe the problem being solved and the solution.

  1. Solution Voting on Disagreements:

If multiple core developers propose different solutions to the same problem, all core developers will collectively vote on which approach to take using a simple majority vote. The PR is only submitted after a decision is made.

  1. Voting on Self-Submitted Issues:

Core developers can work on PRs for issues they submit, but the issues must be approved by a core developer vote.

  1. Comprehensive Comments and Updates:

Code submitted by core developers should contain detailed code comments. Related documentation, examples, and unit tests should also be updated to reflect changes in the code. And pr should never decrease the code coverage. This ensures the codebase maintains good records and accessibility for other developers, and consistency of features gets tested and verified.

  1. Termination for Prolonged Inactivity:

Core developers who do not participate in reviews and votes for a prolonged period may be removed from their role.

  1. Draft Mode for PRs:

PRs must be set to draft mode until ready for merge. PRs ready for merge require voluntary reviews from several other core developers.

  1. Forced Reviews on Stagnant PRs (non-plan prs):

If a PR does not get enough reviews within one month, all core developers must forcibly participate in the review process.

  1. Activity-Based Incentives:

Incentives for core developers are determined by their activity levels, managed by NGD. Factors like voting, reviewing, submitting, opening issues and PRs, and participating in discussions may contribute to activity metrics.

  1. Respecting Voting Outcomes:

Core developers must respect and adhere to the outcomes of the voting process.

Jim8y avatar Nov 09 '23 11:11 Jim8y