Thanks for putting this together, Jia. > If a change is trivial, or you have the code ready, you > can open a PR directly; otherwise create an issue for > discussion before starting writing code.
This is one of those things that sound like a good idea initially, but then judging whether we need an issue or not may not be entirely obvious. Or perhaps, we think the issue won't require discussion and the discussion ends up happening. I know there is redundancy between issue and pull request in github and a discussion on the pull request is also valid, but to keep the rules simple and clear, 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. Also, if we have an issue for each pull request, then we can make the commit message look like: "BK-1024: My cute little issue" plus a short change log description if we want. > sub-tasks 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. > workflow 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? -Flavio On Sun, Jun 11, 2017 at 12:49 AM, Jia Zhai <zhaiji...@gmail.com> wrote: > Hi all, > > I've put up a proposal > <https://cwiki.apache.org/confluence/display/BOOKKEEPER/ > BP-9+-+Github+issues+for+Issue+Tracking> > on how to use Github issues, try to start with very simple steps. Any > thoughts? > > Best Regards. > -Jia >
