Modification of the documentation of the issue accepting process in the OTP Community

[rejkmackan]

Summary

This PR is a suggestion for modification of the documentation of the issue accepting process in the OTP Community. Background for the suggestion can be found here: docs.google.com/document/d/1Ct3VSt1B8QD1wBxBofkxm12OmAHhw0Ll4Dbd8ESQNtI/

Issue

No issue.

Unit tests

No unit tests

Documentation

This is a documentation change in the file OpenTripPlanner/doc/dev/decisionrecords/DevelopmentProcessConventions.md

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.25%. Comparing base (fbe4607) to head (919aea2).
⚠️ Report is 170 commits behind head on dev-2.x.

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #6998      +/-   ##
=============================================
+ Coverage      72.18%   72.25%   +0.06%     
- Complexity     19840    19973     +133     
=============================================
  Files           2155     2163       +8     
  Lines          80051    80365     +314     
  Branches        8082     8114      +32     
=============================================
+ Hits           57788    58069     +281     
- Misses         19418    19438      +20     
- Partials        2845     2858      +13     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[t2gran]

Some ideas for future discussion

[t2gran]

Should we remove this or add a line for this update?

[t2gran]

Issue types
GitHub now support types for issues (not for PRs). We SHOULD assign one type to each issue - using templates.

• Bug
• Feature Request for adding or removal of new functionality. Any change in business rules.
• Improvement Existing features are improved by adding more information(doc or fields), making it faster, more accurate or simpler to use. The business rules are not changed.
• Technical Request for a none functional change. Refactoring, architecture, optimization, library change/upgrade.

Notes

1. Issues is describing the problem or the feature someone want. It mappes many-to-many to PRs. A PR might be a minor change, but depending on the solution we choose the issue can be trivial or complex. An issue can not be a Minor Change - we do not know when it is created. Issues are not Refactoring either - they can be none functional, for witch I want to continue using the term Technical (removing Dept).
2. I also want to stay as close to the default types provided by GitHub. For people used to work with GitHub it then become easier to adapt to.
3. The Documentation label is migrated to Improvement type or just a PR.
4. The Optimization label is migrated to Technical type. Optimizations are likely to be high risk, high value, and/or high complexity so we want to tag at least PRs - but it is ok not to have a types for them in issues - we can also use the label in addition.
5. New Functionality is converted to Feature

Workflow / Process Quality Labels
We can use labels for workflow (some thought, needs more work):

• Feature approved
  • Apply to: Bug, Feature, Improvment
  • By:
• Design approved
  • Apply to: All
  • By:
• Rejected
  • Apply to: All
  • By:

[t2gran]

PRs

[TODO Describe PR labels]

• Draft
  • until: feature and design is approved
  • none draft trigger reviewers assignment
• Approved
  • Review
    • Check if PR does what is approved in the issue
• Rejected
  • Explain why
  • Link to replaced-by-PR.

[leonardehrenfried]

I think the requirement for the ticket labels are a good idea.

I'm a little less sure about establishing an "architectural design board". Frankly, I don't think that we will find many volunteers who want to be on it. On top of this, I don't believe that we need more process, but I'm not sure if this is a common sentiment.

[t2gran]

In case an issue or PR is rejected (this is the same process for both):

• Close issue with a reason why it is closed and set milestone to rejected.
• No label - it is redundant

[rejkmackan]

I don't have a strict suggestion for a "architectural design board", but I understand what you mean.

My suggestion is to clarify the need for design approval. Either you try to get it before hand. Otherwise it can wait until the normal review stage, which means a higher risk for the one who wants the change.