Ok, so why don't we make clear what we are voting for? If this vote is approved, then the outcome is that the community is going to work on a plan to move to github issues, and that plan will be voted? Or is it going to be considered a code change and require just a +1 from a committer? The reason I'm insisting is that I like the idea of moving to github issues, but I'm not sure what we are voting for precisely.
As for the approval process, it is not clear from the list of actions which one is the one to take as not a single one is a good match. When this is the case, the binding votes should be the PMC ones, and given that this is a pretty significant change, I'd be more comfortable with lazy consensus. Also, note that the shared resources of the project are responsibility of the PMC. While we can do it in the open to gather feedback from the community, and in fact, I'd say that this makes a lot of sense to do it, it is the PMC responsibility. My recommendation is that we clarify what we are voting for and call a second vote. I'd happy to help out if it comes to that. Thanks, -Flavio > On 03 Jun 2017, at 19:29, Sijie Guo <guosi...@gmail.com> wrote: > > On Sat, Jun 3, 2017 at 7:39 AM, Flavio Junqueira <f...@apache.org> wrote: > >> Thanks for pushing this through, Sijie. I have a couple of concerns about >> this proposal: >> >> 1- There is a proposal, but I'm not seeing a workflow defined for github >> issues. Should we define one and make that part of the vote? >> > > Defining a workflow requires efforts and putting attentions into the > community. The vote carries the proposal from last sync up to achieve a > consensus in the community - "shall we try out github issues". If the > community agrees on this, we can call for volunteers to drive the > discussion on defining a workflow and help with logistics (e.g. works with > INFRA team) to make it happen. > > If the community isn't interested in moving forward, it doesn't make any > sense to put the efforts on it. > > >> 2- I'm not sure what the binding votes are and what the approval process >> is. Are we following the project bylaws here? >> > > http://bookkeeper.apache.org/bylaws.html > > This is related to development/release workflow, is counted as "Release > Plan". It follows the "Lazy majority" approval process, any votes from > committers are binding votes. > > The voting period is 3 days. > > - Sijie > > >> >> Thanks, >> -Flavio >> >>> On 01 Jun 2017, at 21:59, Sijie Guo <guosi...@gmail.com> wrote: >>> >>> Per the community meeting >>> <https://cwiki.apache.org/confluence/display/BOOKKEEPER/ >> 2017-06-01+Meeting+notes> >>> this morning, JV proposed to start use Github issues for issue tracking >> for >>> a few months and see how does it work out. I am starting this email >> thread >>> to vote for this. >>> >>> The vote will be: >>> >>> - Start using Github issues/pull requests for issue tracking for 3 >> months. >>> - During this 3 months, we will continue using both JIRA and Github >> issues. >>> - After 3 months, if the community decides whether we should continue >> using >>> Github issues or moving from JIRA to Github issues. (The final decision >>> will be a separate vote in 3 months) >>> >>> Please vote +1 if in favor of trying out Github issues and -1 if not. >>> >>> See below thread and community meeting notes >>> <https://cwiki.apache.org/confluence/display/BOOKKEEPER/ >> 2017-06-01+Meeting+notes> >>> for reference: >>> >>> http://mail-archives.apache.org/mod_mbox/bookkeeper-dev/201705.mbox/% >> 3CCAO2yDyYKmUiSfGfkGCKtfP8mmQtcJubGoMO-KsWsjM9_3pOd0Q%40mail.gmail.com%3E >>> >>> - Sijie >> >>
