Hi Enrico, Sijie And Flavio, Thanks a lot for the great comments on this. the BP have changed following the comments.
``` I think the labels/milestones can work as you described, but maybe we can consider to use composite labels like component/server or type/improvement. ``` < == seems "server" could be included in label "bookie", and "improvement" could be included in label "task" ``` In jira, we submit a patch when a contributor wants it merged and a committer cancels the patch when there are necessary changes. Do we want to implement a similar workflow using labels? ``` < == We could control it in github pull request by feature "review changes" tab, right? As currently it is a try period, How about make the lablels simple as currently? ``` It might be worth adding a point to the proposal about sub-tasks as this is probably how we will be working with umbrella issues: use (- [ ]) for each subtask and create a corresponding issue to map to the sub-task. ``` < == have changed the issue_template to include suggestion for subtasks. ``` we could just say that we always create an issue for a pull request and the only discussions on the pull requests are the ones about the code changes ``` < == have changed this in the BP, to always create an issue for change. Regarding the permissions, have opened INFRA issue <https://issues.apache.org/jira/browse/INFRA-14337> to confirm. Regarding the release part, we will start a new BP to discuss it, such as the release procedures, how to prepare the release notes, etc. Thanks a lot. -Jia
