New rules and labels for the polkadot repo #2
Conversation
Before merge to-dos: [] Make sure the release notes scripts are using 'B1-note_worthy' instead of 'B1-runtimenoteworthy' [] Makes sure the new C* labels are also replaced in the script for creating the release notes [] Make sure that the CI refers to the D* label rules in this file when there were changes in these paths: - '^runtime/polkadot' - '^runtime/kusama' - '^primitives/src/' - '^runtime/common' cc: @coderobe
| - name: E2-dependencies | ||
| description: Pull requests that update a dependency file. | ||
| color: "222211" | ||
| - name: E3-host_functions |
There was a problem hiding this comment.
What's the point of this? it seems like a pure subset of the next item.
| description: This PR/Issue is related to the topic “runtime”. | ||
| color: F5FCE6 | ||
| - name: T2-API | ||
| description: This PR/Issue is related to APIs. |
There was a problem hiding this comment.
Which API? RPC api? runtime api? rust crate api?
There was a problem hiding this comment.
we can extend the options here, right now it's very generic
| description: PR introduces code that does a one-way migration of the database. | ||
| color: "112233" | ||
| - name: E2-dependencies | ||
| description: Pull requests that update a dependency file. |
There was a problem hiding this comment.
Could we automatically enforce this through the CI by checking for changes in the Cargo.lock files?
There was a problem hiding this comment.
I think so but I need more info about the logic how it should be checked/triggered. It seems that it's going to be a custom job.
There was a problem hiding this comment.
Me neither. @the-right-joyce could you please put it into a new issue so we can keep track of it? https://github.com/paritytech/ci_cd/issues
| - name: J5-wont_fix | ||
| description: "Issue is in principle valid, but this project will not address it. Closer should explain why." | ||
| color: FB3701 | ||
| - name: J6-invalid |
There was a problem hiding this comment.
Not sure where it fits best: But a reserved label similar to the mentor label would be nice - to indicate that an issue should not be picked up by anyone unless approved.
There was a problem hiding this comment.
and who should be the one to approve this issue?
There was a problem hiding this comment.
Just someone from Parity in general. That person should then know why the reserved label was on there.
Currently we often have the case that external contributors "snatch" issues that we had reserved for someone new as on-boarding task.
There was a problem hiding this comment.
do we really want to do this as an open source project?
There was a problem hiding this comment.
My problem currently is that some advanced external devs are swooping up easy issues that we ought to keep for new-comers as entry to Substrate.
Even that label won't prevent them from working on it, but hopefully make them ask first.
implemented all changes requested added rule that requires T0 and T1
the-right-joyce
requested review from
alvicsam and
kianenigma
and removed request for
kianenigma
Before merge to-dos:
After merge to-dos: