You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bookkeeper.apache.org by Sijie Guo <gu...@gmail.com> on 2017/06/01 19:59:47 UTC
[VOTE] Use Github Issues for Issue Tracking
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
Re: [VOTE] Use Github Issues for Issue Tracking
Posted by Flavio Junqueira <fp...@apache.org>.
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?
2- I'm not sure what the binding votes are and what the approval process is. Are we following the project bylaws here?
Thanks,
-Flavio
> On 01 Jun 2017, at 21:59, Sijie Guo <gu...@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
Re: [VOTE] Use Github Issues for Issue Tracking
Posted by Enrico Olivelli <eo...@gmail.com>.
+1 let's try github
Il gio 1 giu 2017, 21:59 Sijie Guo <gu...@gmail.com> ha scritto:
> 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
>
--
-- Enrico Olivelli
Re: [VOTE] Use Github Issues for Issue Tracking
Posted by Flavio Junqueira <fp...@apache.org>.
Sure, feel free to close the vote. Thanks for bearing with me.
-Flavio
> On 06 Jun 2017, at 18:07, Sijie Guo <gu...@gmail.com> wrote:
>
> On Tue, Jun 6, 2017 at 12:41 AM, Flavio Junqueira <fpj@apache.org <ma...@apache.org>> wrote:
>
>>
>>> On 05 Jun 2017, at 18:30, Sijie Guo <gu...@gmail.com> wrote:
>>>
>>> On Mon, Jun 5, 2017 at 2:53 AM, Flavio Junqueira <fp...@apache.org> wrote:
>>>
>>>> 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?
>>>
>>>
>>> I believed that I made the clarification on what to vote in this thread.
>>>
>>
>> This is probably where we are not converging. I don't know what passing
>> this vote entails other than a wish to move to github issues in the case it
>> passes. I'd much rather vote on a proposal that includes the precise steps
>> so that we can assess whether that's a good move or not. But wait, you say
>> something interesting next...
>>
>>> Implementing the new github workflow would be a separated bookkeeper
>>> proposal and that implementation will follow bookkeeper proposal process
>> to
>>> vote, which is a lazy majority vote from committers.
>>>
>>> Anyone are welcome to work on implementing the workflow.
>>>
>>
>> I see, we aren't really voting on a change or committing to anything, you
>> just want to assess preferences.
>>
>>>
>>>> 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.
>>>>
>>>
>>> Thanks for pointing it out. Yes, the binding votes for this will be
>> active
>>> PMC members.
>>>
>>> Although I have a different personal opinion on the responsibility on
>>> shared resources. My feel is the shared resources are more developer
>>> resources, which committers/developers should own more responsibilities.
>> We
>>> can discuss it separately.
>>
>> It is not really my preference, this is in the bylaws of the project. It
>> is a responsibility of the PMC to maintain shared resources. I think that
>> the issue tracking application is a shared resource.
>>
>>>
>>>
>>>> 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.
>>>>
>>>
>>> Let me know if the clarification is good to you or not.
>>
>> Possibly, if this vote is about declaring intention rather than
>> committing, then I'm totally good with that.
>>
>
> Flavio, if you are good with that, I would like to close this vote, so that
> we can move forward to make it happen.
>
> If you have a proposal on the workflow, feel free to raise it up as a BP.
>
> - Sijie
>
>
>>
>> -Flavio
>>
>>>
>>>
>>>>
>>>> Thanks,
>>>> -Flavio
>>>>
>>>>
>>>>> On 03 Jun 2017, at 19:29, Sijie Guo <gu...@gmail.com> wrote:
>>>>>
>>>>> On Sat, Jun 3, 2017 at 7:39 AM, Flavio Junqueira <fp...@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 <gu...@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
Re: [VOTE] Use Github Issues for Issue Tracking
Posted by Sijie Guo <gu...@gmail.com>.
On Tue, Jun 6, 2017 at 12:41 AM, Flavio Junqueira <fp...@apache.org> wrote:
>
> > On 05 Jun 2017, at 18:30, Sijie Guo <gu...@gmail.com> wrote:
> >
> > On Mon, Jun 5, 2017 at 2:53 AM, Flavio Junqueira <fp...@apache.org> wrote:
> >
> >> 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?
> >
> >
> > I believed that I made the clarification on what to vote in this thread.
> >
>
> This is probably where we are not converging. I don't know what passing
> this vote entails other than a wish to move to github issues in the case it
> passes. I'd much rather vote on a proposal that includes the precise steps
> so that we can assess whether that's a good move or not. But wait, you say
> something interesting next...
>
> > Implementing the new github workflow would be a separated bookkeeper
> > proposal and that implementation will follow bookkeeper proposal process
> to
> > vote, which is a lazy majority vote from committers.
> >
> > Anyone are welcome to work on implementing the workflow.
> >
>
> I see, we aren't really voting on a change or committing to anything, you
> just want to assess preferences.
>
> >
> >> 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.
> >>
> >
> > Thanks for pointing it out. Yes, the binding votes for this will be
> active
> > PMC members.
> >
> > Although I have a different personal opinion on the responsibility on
> > shared resources. My feel is the shared resources are more developer
> > resources, which committers/developers should own more responsibilities.
> We
> > can discuss it separately.
>
> It is not really my preference, this is in the bylaws of the project. It
> is a responsibility of the PMC to maintain shared resources. I think that
> the issue tracking application is a shared resource.
>
> >
> >
> >> 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.
> >>
> >
> > Let me know if the clarification is good to you or not.
>
> Possibly, if this vote is about declaring intention rather than
> committing, then I'm totally good with that.
>
Flavio, if you are good with that, I would like to close this vote, so that
we can move forward to make it happen.
If you have a proposal on the workflow, feel free to raise it up as a BP.
- Sijie
>
> -Flavio
>
> >
> >
> >>
> >> Thanks,
> >> -Flavio
> >>
> >>
> >>> On 03 Jun 2017, at 19:29, Sijie Guo <gu...@gmail.com> wrote:
> >>>
> >>> On Sat, Jun 3, 2017 at 7:39 AM, Flavio Junqueira <fp...@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 <gu...@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
> >>>>
> >>>>
> >>
> >>
>
>
Re: [VOTE] Use Github Issues for Issue Tracking
Posted by Sijie Guo <gu...@gmail.com>.
On Tue, Jun 6, 2017 at 12:41 AM, Flavio Junqueira <fp...@apache.org> wrote:
>
> > On 05 Jun 2017, at 18:30, Sijie Guo <gu...@gmail.com> wrote:
> >
> > On Mon, Jun 5, 2017 at 2:53 AM, Flavio Junqueira <fp...@apache.org> wrote:
> >
> >> 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?
> >
> >
> > I believed that I made the clarification on what to vote in this thread.
> >
>
> This is probably where we are not converging. I don't know what passing
> this vote entails other than a wish to move to github issues in the case it
> passes. I'd much rather vote on a proposal that includes the precise steps
> so that we can assess whether that's a good move or not. But wait, you say
> something interesting next...
>
> > Implementing the new github workflow would be a separated bookkeeper
> > proposal and that implementation will follow bookkeeper proposal process
> to
> > vote, which is a lazy majority vote from committers.
> >
> > Anyone are welcome to work on implementing the workflow.
> >
>
> I see, we aren't really voting on a change or committing to anything, you
> just want to assess preferences.
We are not committing to moving away from Jira to Github. The consensus we
try to achieve at this stage is "use Github for tracking issues in next 3
months". Then the community votes based on the user experiences in 3 months
and decide whether we should commit to Github or not.
"How to use Github" - what is the workflow, what are the best practices and
what features that we need to ask INFRA team to enable - these are
something that the community need to develop and come up during this
try-out period. I don't expect each of these tasks need to go through
voting process. Once we agrees on "trying-out", there are tasks can run in
parallel and iterate fast.
We can make any proposal based on precise steps on using Github. But people
doesn't really feel it until start using it.
>
> >
> >> 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.
> >>
> >
> > Thanks for pointing it out. Yes, the binding votes for this will be
> active
> > PMC members.
> >
> > Although I have a different personal opinion on the responsibility on
> > shared resources. My feel is the shared resources are more developer
> > resources, which committers/developers should own more responsibilities.
> We
> > can discuss it separately.
>
> It is not really my preference, this is in the bylaws of the project. It
> is a responsibility of the PMC to maintain shared resources. I think that
> the issue tracking application is a shared resource.
>
yes, we are following the bylaws now. but as I said, personally I think
committers should own more responsibilities on this piece. we can raise a
separate discussion if needed.
>
> >
> >
> >> 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.
> >>
> >
> > Let me know if the clarification is good to you or not.
>
> Possibly, if this vote is about declaring intention rather than
> committing, then I'm totally good with that.
>
> -Flavio
>
> >
> >
> >>
> >> Thanks,
> >> -Flavio
> >>
> >>
> >>> On 03 Jun 2017, at 19:29, Sijie Guo <gu...@gmail.com> wrote:
> >>>
> >>> On Sat, Jun 3, 2017 at 7:39 AM, Flavio Junqueira <fp...@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 <gu...@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
> >>>>
> >>>>
> >>
> >>
>
>
Re: [VOTE] Use Github Issues for Issue Tracking
Posted by Flavio Junqueira <fp...@apache.org>.
> On 05 Jun 2017, at 18:30, Sijie Guo <gu...@gmail.com> wrote:
>
> On Mon, Jun 5, 2017 at 2:53 AM, Flavio Junqueira <fp...@apache.org> wrote:
>
>> 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?
>
>
> I believed that I made the clarification on what to vote in this thread.
>
This is probably where we are not converging. I don't know what passing this vote entails other than a wish to move to github issues in the case it passes. I'd much rather vote on a proposal that includes the precise steps so that we can assess whether that's a good move or not. But wait, you say something interesting next...
> Implementing the new github workflow would be a separated bookkeeper
> proposal and that implementation will follow bookkeeper proposal process to
> vote, which is a lazy majority vote from committers.
>
> Anyone are welcome to work on implementing the workflow.
>
I see, we aren't really voting on a change or committing to anything, you just want to assess preferences.
>
>> 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.
>>
>
> Thanks for pointing it out. Yes, the binding votes for this will be active
> PMC members.
>
> Although I have a different personal opinion on the responsibility on
> shared resources. My feel is the shared resources are more developer
> resources, which committers/developers should own more responsibilities. We
> can discuss it separately.
It is not really my preference, this is in the bylaws of the project. It is a responsibility of the PMC to maintain shared resources. I think that the issue tracking application is a shared resource.
>
>
>> 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.
>>
>
> Let me know if the clarification is good to you or not.
Possibly, if this vote is about declaring intention rather than committing, then I'm totally good with that.
-Flavio
>
>
>>
>> Thanks,
>> -Flavio
>>
>>
>>> On 03 Jun 2017, at 19:29, Sijie Guo <gu...@gmail.com> wrote:
>>>
>>> On Sat, Jun 3, 2017 at 7:39 AM, Flavio Junqueira <fp...@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 <gu...@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
>>>>
>>>>
>>
>>
Re: [VOTE] Use Github Issues for Issue Tracking
Posted by Sijie Guo <gu...@gmail.com>.
On Mon, Jun 5, 2017 at 2:53 AM, Flavio Junqueira <fp...@apache.org> wrote:
> 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?
I believed that I made the clarification on what to vote in this thread.
Implementing the new github workflow would be a separated bookkeeper
proposal and that implementation will follow bookkeeper proposal process to
vote, which is a lazy majority vote from committers.
Anyone are welcome to work on implementing the workflow.
> 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.
>
Thanks for pointing it out. Yes, the binding votes for this will be active
PMC members.
Although I have a different personal opinion on the responsibility on
shared resources. My feel is the shared resources are more developer
resources, which committers/developers should own more responsibilities. We
can discuss it separately.
> 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.
>
Let me know if the clarification is good to you or not.
>
> Thanks,
> -Flavio
>
>
> > On 03 Jun 2017, at 19:29, Sijie Guo <gu...@gmail.com> wrote:
> >
> > On Sat, Jun 3, 2017 at 7:39 AM, Flavio Junqueira <fp...@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 <gu...@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
> >>
> >>
>
>
Re: [VOTE] Use Github Issues for Issue Tracking
Posted by Flavio Junqueira <fp...@apache.org>.
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 <gu...@gmail.com> wrote:
>
> On Sat, Jun 3, 2017 at 7:39 AM, Flavio Junqueira <fp...@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 <gu...@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
>>
>>
Re: [VOTE] Use Github Issues for Issue Tracking
Posted by Sijie Guo <gu...@gmail.com>.
On Sat, Jun 3, 2017 at 7:39 AM, Flavio Junqueira <fp...@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 <gu...@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
>
>
Re: [VOTE] Use Github Issues for Issue Tracking
Posted by Flavio Junqueira <fp...@apache.org>.
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?
2- I'm not sure what the binding votes are and what the approval process is. Are we following the project bylaws here?
Thanks,
-Flavio
> On 01 Jun 2017, at 21:59, Sijie Guo <gu...@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
Re: [VOTE] Use Github Issues for Issue Tracking
Posted by Jia Zhai <zh...@gmail.com>.
+1
The simpler the better.
On Fri, Jun 2, 2017 at 9:16 PM, Ivan Kelly <iv...@apache.org> wrote:
> +1 from me. Always good to reduce barriers to participation.
>
> -Ivan
>
> On Fri, Jun 2, 2017 at 12:29 AM, Matteo Merli <mm...@apache.org> wrote:
> > +1
> >
> > Having issues and PR in one tool is a great plus.
> >
> > If this proposal is accepted, we should also ask INFRA to allow to assign
> > issues/PRs to committers/contributors and to create labels that fit our
> > workflow.
> >
> >
> > On Thu, Jun 1, 2017 at 3:03 PM Sijie Guo <gu...@gmail.com> wrote:
> >
> >> My vote on this is +1.
> >>
> >> Simply because I'd like to have one central place for tracking issues
> and
> >> reviewing pull requests.
> >>
> >> - Sijie
> >>
> >> On Thu, Jun 1, 2017 at 12:59 PM, Sijie Guo <gu...@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
> >> >
> >>
>
Re: [VOTE] Use Github Issues for Issue Tracking
Posted by Ivan Kelly <iv...@apache.org>.
+1 from me. Always good to reduce barriers to participation.
-Ivan
On Fri, Jun 2, 2017 at 12:29 AM, Matteo Merli <mm...@apache.org> wrote:
> +1
>
> Having issues and PR in one tool is a great plus.
>
> If this proposal is accepted, we should also ask INFRA to allow to assign
> issues/PRs to committers/contributors and to create labels that fit our
> workflow.
>
>
> On Thu, Jun 1, 2017 at 3:03 PM Sijie Guo <gu...@gmail.com> wrote:
>
>> My vote on this is +1.
>>
>> Simply because I'd like to have one central place for tracking issues and
>> reviewing pull requests.
>>
>> - Sijie
>>
>> On Thu, Jun 1, 2017 at 12:59 PM, Sijie Guo <gu...@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
>> >
>>
Re: [VOTE] Use Github Issues for Issue Tracking
Posted by Matteo Merli <mm...@apache.org>.
+1
Having issues and PR in one tool is a great plus.
If this proposal is accepted, we should also ask INFRA to allow to assign
issues/PRs to committers/contributors and to create labels that fit our
workflow.
On Thu, Jun 1, 2017 at 3:03 PM Sijie Guo <gu...@gmail.com> wrote:
> My vote on this is +1.
>
> Simply because I'd like to have one central place for tracking issues and
> reviewing pull requests.
>
> - Sijie
>
> On Thu, Jun 1, 2017 at 12:59 PM, Sijie Guo <gu...@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
> >
>
Re: [VOTE] Use Github Issues for Issue Tracking
Posted by Sijie Guo <gu...@gmail.com>.
My vote on this is +1.
Simply because I'd like to have one central place for tracking issues and
reviewing pull requests.
- Sijie
On Thu, Jun 1, 2017 at 12:59 PM, Sijie Guo <gu...@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
>