Re: [DISCUSS] Default assignee on new plugin JIRA issues (was: Re: Request to be made maintainer of ant-plugin)

[domi]

My first thought was that I would like to keep the default assignee - but after 
reading all the comments, I have to agree, that my only reason for this is so 
that I get notified by new issues. Although Oleg shoed it is possible to create 
a filter and get notified about this things, It seems quite complicated and 
many maintainers will not do it and therefore not get any info about new 
issues. So I think there should be some kind of easy way to at least inform the 
official maintainer - maybe we can even create these filters automatically…
/Domi


> On 6 Sep 2019, at 01:37, Ullrich Hafner  wrote:
> 
> Making it an optional field in the HOSTING report seems to be a good 
> compromise, so +1 from me for such a change.
> 
> (I understand that developers do not want to be assignee for issues they are 
> never going to fix. On the other hands, for a user that reports an issue it 
> is somewhat disappointing that no one actually cares about his new issue. 
> This will indicate that it is not worth to report an issue at all.)
>  
> 
>> Am 05.09.2019 um 20:40 schrieb Slide > >:
>> 
>> We should add a field in the HOSTING Jira that allows people to specify if 
>> they want to be set as the default assignee, then the bot can check that 
>> field before setting up the default assignee for the component. We would 
>> need someone with admin access on Jira to add the field. I can create a PR 
>> for the bot once the field is setup.
>> 
>> On Thu, Sep 5, 2019, 11:35 Matt Sicker > > wrote:
>> That makes tons of sense to me. You should only assign tickets to
>> yourself that you're currently working on or at least intend to work
>> on in the near future.
>> 
>> On Thu, Sep 5, 2019 at 4:31 AM Baptiste Mathus > > wrote:
>> >
>> > I fully agree with Jesse's take. IMO for most plugins where the maintainer 
>> > is not going to have time to jump on new reports right away, this sends a 
>> > wrong message that issues will be analyzed and fixed by the assignee.
>> > This sends a second bad message: that an issue being already assigned, 
>> > this is not necessary that someone steps up to work on a fix proposal.
>> >
>> > AIUI, the default assignee is often used by maintainers as a nice way to 
>> > be notified when a new issue arises, but on average not meaning that that 
>> > given maintainer will commit to address in a timely manner anything new 
>> > that comes in.
>> >
>> > IOW, my main point is that I think we should allow maintainers to be made 
>> > default assignee, but we should default to having no default assignee.
>> >
>> > Le mar. 27 août 2019 à 15:14, Jesse Glick > > > a écrit :
>> >>
>> >> On Tue, Aug 27, 2019 at 8:54 AM Oleg Nenashev > >> > wrote:
>> >> > a default assignee for the component
>> >>
>> >> As always, I prefer there to be no default assignee for a JIRA
>> >> component. It is not a helpful concept IMO. If and when I decide to
>> >> tackle an issue, I will assign it to myself.
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google Groups 
>> >> "Jenkins Developers" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send an 
>> >> email to jenkinsci-dev+unsubscr...@googlegroups.com 
>> >> .
>> >> To view this discussion on the web visit 
>> >> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2MLHtwCNgQhbLCBjV78NVPSCUs0zUs2_zDChw6Aad5bw%40mail.gmail.com
>> >>  
>> >> .
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups 
>> > "Jenkins Developers" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an 
>> > email to jenkinsci-dev+unsubscr...@googlegroups.com 
>> > .
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7J1661hacPVP9rMN5sK%2Bz_Hsos28Bd8N%2BNbxwxMouWNA%40mail.gmail.com
>> >  
>> > .
>> 
>> 
>> 
>> -- 
>> Matt Sicker
>> Senior Software Engineer, CloudBees
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-dev+unsubscr...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4ox7Xqp9gzdht-R7GYHjs%2B%3DUdw2Yk32H91pnvyUw9axRZw%40mail.gmail.com
>>  
>> 

Jenkins Board & Officer Elections 2019

[Lloyd Chang]

Hi, Tracy,

Ask — Would you kindly update Board Election Process at 
https://wiki.jenkins.io/x/lIHPAw and describe your proposal there?

Intent of my (meta-level) ask is to align (newcomer) people’s knowledge 
acquisition based on existing centralized information on wiki.jenkins.io web 
site with revision history.

Thank you,
Lloyd

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/b88092c6-9796-46a7-9012-f87d3c782378%40googlegroups.com.

Re: Jenkins Board & Officer Elections 2019

[Mark Waite]

I like the idea and the timeline.

On Thu, Sep 5, 2019 at 6:35 PM Rick  wrote:

> Yes, plus from me. It might be not very clear for everyone.
>
> On Fri, Sep 6, 2019 at 8:32 AM Marky Jackson 
> wrote:
>
>> Tracy,
>> I think this is a great thing.
>> In looking at the election process I wonder if it would be good to have a
>> meeting to discuss any confusion voters may have?
>>
>>
>> On Sep 4, 2019, at 1:38 PM, Tracy Miranda  wrote:
>>
>> Hi all,
>>
>> As you may or may not know Jenkins project is run by a Governance Board
>> with support from a set of Officers.
>>
>> While a process has been set out for elections we are overdue an
>> election. With Jenkins moving from SPI to CDF
>>  the timing is good to
>> do this. CD.Foundation is a multi-project foundation with corporate
>> sponsors and various oversight bodies. The nature of the foundation means
>> we need to ensure good channels for communications and a robust operating
>> model.
>>
>> With that in mind I am proposing the following set of dates for running a
>> new elections. The election process will be bootstrapped by the existing
>> board and we will request CDF run and supervise the election using the The
>> Condorcet Internet voting system .
>>
>> Please review the proposal below and links outlining the process for new
>> board and officer elections.
>>
>> 2019 Election Schedule
>>
>> (Proposed):
>>
>> 13 September, 2019: Nominations open. To nominate someone, send an email
>> to jenkinsci-bo...@googlegroups.com
>>
>> 4 October, 2019: Nominations close
>>
>> 8 October, 2019: List of nominees posted to (mailing list)
>>
>> 11 October, 2019: Nominees’ personal statements made available
>>
>> 14 October, 2019: Voting begins
>>
>> 27 October, 2019: Voting closes 5pm Pacific Time
>>
>> 4 November, 2019: New representatives announced
>>
>> For voting eligibility I propose we generally stick with the process
>> outlined in the Board Election Process
>>  with
>> the following specific modifications:
>>
>>
>>- cut-off date for voter eligibility being September 1st 2019.
>>- I would also like to propose that any Jenkins contributor who does
>>not meet the eligibility criteria but is a community contributor can also
>>register to vote by writing to the existing board of directors. (as I have
>>been made aware of a subset of contributors who potentially fall in this
>>category)
>>
>>
>> Please review the above and share your thoughts. Ideally we discuss now
>> with the goal of reaching consensus by the next governance meeting on
>> August 11th when we can finalize/ratify the proposal.
>>
>> If you are happy with the proposal I hope you will consider putting
>> yourself forward for one of the positions.
>>
>> Regards,
>> Tracy
>>
>>
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CACTaz6rerrEu%3D4qUEZWX2YaB55LrD8PWAtp70H%3D8Pn6fvswKPg%40mail.gmail.com
>> 
>> .
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/6F9E3741-5BCF-4A49-8053-64AF0477C241%40gmail.com
>> 
>> .
>>
>
>
> --
> Zhao Xiaojie (Rick)
> Blog: https://github.com/LinuxSuRen
> Twitter: https://twitter.com/suren69811254
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTHorq2-aGuFzjmvOsE%3DV-AtVxGw3_7uRuGGcm%2BFCBtDLQ%40mail.gmail.com
> 
> .
>


-- 
Thanks!
Mark Waite

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the 

Re: Jenkins Board & Officer Elections 2019

[Rick]

Yes, plus from me. It might be not very clear for everyone.

On Fri, Sep 6, 2019 at 8:32 AM Marky Jackson 
wrote:

> Tracy,
> I think this is a great thing.
> In looking at the election process I wonder if it would be good to have a
> meeting to discuss any confusion voters may have?
>
>
> On Sep 4, 2019, at 1:38 PM, Tracy Miranda  wrote:
>
> Hi all,
>
> As you may or may not know Jenkins project is run by a Governance Board
> with support from a set of Officers.
>
> While a process has been set out for elections we are overdue an election.
> With Jenkins moving from SPI to CDF
>  the timing is good to do
> this. CD.Foundation is a multi-project foundation with corporate sponsors
> and various oversight bodies. The nature of the foundation means we need to
> ensure good channels for communications and a robust operating model.
>
> With that in mind I am proposing the following set of dates for running a
> new elections. The election process will be bootstrapped by the existing
> board and we will request CDF run and supervise the election using the The
> Condorcet Internet voting system .
>
> Please review the proposal below and links outlining the process for new
> board and officer elections.
>
> 2019 Election Schedule
>
> (Proposed):
>
> 13 September, 2019: Nominations open. To nominate someone, send an email
> to jenkinsci-bo...@googlegroups.com
>
> 4 October, 2019: Nominations close
>
> 8 October, 2019: List of nominees posted to (mailing list)
>
> 11 October, 2019: Nominees’ personal statements made available
>
> 14 October, 2019: Voting begins
>
> 27 October, 2019: Voting closes 5pm Pacific Time
>
> 4 November, 2019: New representatives announced
>
> For voting eligibility I propose we generally stick with the process
> outlined in the Board Election Process
>  with the
> following specific modifications:
>
>
>- cut-off date for voter eligibility being September 1st 2019.
>- I would also like to propose that any Jenkins contributor who does
>not meet the eligibility criteria but is a community contributor can also
>register to vote by writing to the existing board of directors. (as I have
>been made aware of a subset of contributors who potentially fall in this
>category)
>
>
> Please review the above and share your thoughts. Ideally we discuss now
> with the goal of reaching consensus by the next governance meeting on
> August 11th when we can finalize/ratify the proposal.
>
> If you are happy with the proposal I hope you will consider putting
> yourself forward for one of the positions.
>
> Regards,
> Tracy
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CACTaz6rerrEu%3D4qUEZWX2YaB55LrD8PWAtp70H%3D8Pn6fvswKPg%40mail.gmail.com
> 
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/6F9E3741-5BCF-4A49-8053-64AF0477C241%40gmail.com
> 
> .
>


-- 
Zhao Xiaojie (Rick)
Blog: https://github.com/LinuxSuRen
Twitter: https://twitter.com/suren69811254

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAMM7nTHorq2-aGuFzjmvOsE%3DV-AtVxGw3_7uRuGGcm%2BFCBtDLQ%40mail.gmail.com.

Re: Jenkins Board & Officer Elections 2019

[Marky Jackson]

Tracy,
I think this is a great thing. 
In looking at the election process I wonder if it would be good to have a 
meeting to discuss any confusion voters may have?


> On Sep 4, 2019, at 1:38 PM, Tracy Miranda  wrote:
> 
> Hi all, 
> 
> As you may or may not know Jenkins project is run by a Governance Board with 
> support from a set of Officers. 
> 
> While a process has been set out for elections we are overdue an election. 
> With Jenkins moving from SPI to CDF 
>  the timing is good to do 
> this. CD.Foundation is a multi-project foundation with corporate sponsors and 
> various oversight bodies. The nature of the foundation means we need to 
> ensure good channels for communications and a robust operating model. 
> 
> With that in mind I am proposing the following set of dates for running a new 
> elections. The election process will be bootstrapped by the existing board 
> and we will request CDF run and supervise the election using the The 
> Condorcet Internet voting system .
> 
> Please review the proposal below and links outlining the process for new 
> board and officer elections. 
> 
> 2019 Election Schedule
> (Proposed):
> 13 September, 2019: Nominations open. To nominate someone, send an email to 
> jenkinsci-bo...@googlegroups.com 
> 4 October, 2019: Nominations close
> 8 October, 2019: List of nominees posted to (mailing list)
> 11 October, 2019: Nominees’ personal statements made available
> 14 October, 2019: Voting begins
> 27 October, 2019: Voting closes 5pm Pacific Time
> 4 November, 2019: New representatives announced
> For voting eligibility I propose we generally stick with the process outlined 
> in the Board Election Process 
>  with the 
> following specific modifications:
> 
> cut-off date for voter eligibility being September 1st 2019.
> I would also like to propose that any Jenkins contributor who does not meet 
> the eligibility criteria but is a community contributor can also register to 
> vote by writing to the existing board of directors. (as I have been made 
> aware of a subset of contributors who potentially fall in this category)
> 
> Please review the above and share your thoughts. Ideally we discuss now with 
> the goal of reaching consensus by the next governance meeting on August 11th 
> when we can finalize/ratify the proposal. 
> 
> If you are happy with the proposal I hope you will consider putting yourself 
> forward for one of the positions. 
> 
> Regards,
> Tracy
> 
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CACTaz6rerrEu%3D4qUEZWX2YaB55LrD8PWAtp70H%3D8Pn6fvswKPg%40mail.gmail.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/6F9E3741-5BCF-4A49-8053-64AF0477C241%40gmail.com.

Re: Jenkins Board & Officer Elections 2019

[Rick]

+1

On Fri, Sep 6, 2019 at 8:08 AM Marky Jackson 
wrote:

> I also +1 this.
>
> On Sep 5, 2019, at 5:04 PM, Oleg Nenashev  wrote:
>
> Hi all,
>
> Strong +1 from me for having an election. The board election issue was
> already a really visible issue in 2015 when we had a discussion of the
> board election process. The Board Election Process
>  referenced
> by Tracy was an outcome of months of discussions in the community. The
> process was signed off by the governance meeting though many current key
> contributors were not in the community in 2015. The vote itself has never
> happened due to the voting system implementation issues, but there was a
> strong consensus that we do need an election. In 2019 it is even more
> needed IMHO, just few reasons:
>
>- The current Jenkins board includes 3 people, but one is completely
>inactive in the community. So we are down to two, which is a pretty bad bus
>factor for a project of the Jenkins' size. Kohsuke and Tyler have a lot of
>commitments in the project and IRL, so having more board members would
>definitely improve the board's bandwidth
>- Some critical processes in the Jenkins project are either stalled or
>defunct: regular Governance meetings, JEPs, officer reelections, etc.
>Having an active Jenkins board is instrumental to reviving these processes
>- Migration to CDF requires a lot of changes in the project:
>infrastructure and service accounts handover, trademark approval process,
>etc. It would require extra capacity from the board to coordinate the
>effort and to get it over the line. Jenkins has joined CDF almost 1 year
>ago, but there are still A LOT of open questions about the migration to CDF
>- Lack of Technical Steering Committee in Jenkins, it is one of the
>stories we were originally discussing for "Jenkins Software Foundation" at
>the at Jenkins World 2017. Having an active Jenkins board would be a
>precondition to make this steering committee happen. IMHO we desperately
>need it to work on the Jenkins evolution in the CDF environment where we
>will need to facilitate contributions from individual contributors and
>company contributors. A steering committee would be really helpful to make
>it happen
>
> The proposed schedule is pretty tight assuming that the target Governance
> meeting will happen in Sep 11, but I believe we can make it work if there
> is a consensus. The  Board Election Process
>  defined
> in 2015 still looks pretty solid in 2019, so we could start there. I also
> agree with the changes proposed by Tracy.
>
> Some other questions to answer in the discussion:
>
>- *How many board members do we want to elect?* We are supposed to
>elect only 2 board members at once, but, If we follow the 2015 process,
>2-year terms are long expired. So we can vote for 2, 3 (assuming that Dean
>Yu is inactive) or 4 (if Tyler wants to step down) board members.My
>suggestion would be to elect 2 or 3 board members so that we have a smooth
>transition from the current state
>- *Allowing amendments?* Do we want to use the meeting on Sep 11 to
>vote for suggested amendments to the process like it happened in 2015? I
>would vote for doing so so that all contributors have an opportunity to
>suggest a change and to integrate it into the final process.
>
> Please review the above and share your thoughts. Ideally we discuss now
>> with the goal of reaching consensus by the next governance meeting on
>> August 11th when we can finalize/ratify the proposal.
>>
>
> I think our main goal is to have a consensus about the elections happening
> and about the timeline.
> For the technical implementation of the voting system and process we have
> a bit more time, because the system will be used only on Oct 14.
> It gives us a bit more time to discuss options and to test the voting
> system (e.g. by voting for a best Jenkins logo or other similar fun tooic?
> :) ).
>
> Best regards,
> Oleg
>
>
> On Wednesday, September 4, 2019 at 10:38:22 PM UTC+2, Tracy Miranda wrote:
>>
>> Hi all,
>>
>> As you may or may not know Jenkins project is run by a Governance Board
>> with support from a set of Officers.
>>
>> While a process has been set out for elections we are overdue an
>> election. With Jenkins moving from SPI to CDF
>>  the timing is good to
>> do this. CD.Foundation is a multi-project foundation with corporate
>> sponsors and various oversight bodies. The nature of the foundation means
>> we need to ensure good channels for communications and a robust operating
>> model.
>>
>> With that in mind I am proposing the following set of dates for running a
>> new elections. The election process will be bootstrapped by the existing
>> board and we will request CDF run and 

Re: Jenkins Board & Officer Elections 2019

[Marky Jackson]

I also +1 this.

> On Sep 5, 2019, at 5:04 PM, Oleg Nenashev  wrote:
> 
> Hi all,
> 
> Strong +1 from me for having an election. The board election issue was 
> already a really visible issue in 2015 when we had a discussion of the board 
> election process. The Board Election Process 
>  referenced 
> by Tracy was an outcome of months of discussions in the community. The 
> process was signed off by the governance meeting though many current key 
> contributors were not in the community in 2015. The vote itself has never 
> happened due to the voting system implementation issues, but there was a 
> strong consensus that we do need an election. In 2019 it is even more needed 
> IMHO, just few reasons:
> The current Jenkins board includes 3 people, but one is completely inactive 
> in the community. So we are down to two, which is a pretty bad bus factor for 
> a project of the Jenkins' size. Kohsuke and Tyler have a lot of commitments 
> in the project and IRL, so having more board members would definitely improve 
> the board's bandwidth
> Some critical processes in the Jenkins project are either stalled or defunct: 
> regular Governance meetings, JEPs, officer reelections, etc. Having an active 
> Jenkins board is instrumental to reviving these processes
> Migration to CDF requires a lot of changes in the project: infrastructure and 
> service accounts handover, trademark approval process, etc. It would require 
> extra capacity from the board to coordinate the effort and to get it over the 
> line. Jenkins has joined CDF almost 1 year ago, but there are still A LOT of 
> open questions about the migration to CDF
> Lack of Technical Steering Committee in Jenkins, it is one of the stories we 
> were originally discussing for "Jenkins Software Foundation" at the at 
> Jenkins World 2017. Having an active Jenkins board would be a precondition to 
> make this steering committee happen. IMHO we desperately need it to work on 
> the Jenkins evolution in the CDF environment where we will need to facilitate 
> contributions from individual contributors and company contributors. A 
> steering committee would be really helpful to make it happen
> The proposed schedule is pretty tight assuming that the target Governance 
> meeting will happen in Sep 11, but I believe we can make it work if there is 
> a consensus. The  Board Election Process 
>  defined in 
> 2015 still looks pretty solid in 2019, so we could start there. I also agree 
> with the changes proposed by Tracy.
> 
> Some other questions to answer in the discussion:
> How many board members do we want to elect? We are supposed to elect only 2 
> board members at once, but, If we follow the 2015 process, 2-year terms are 
> long expired. So we can vote for 2, 3 (assuming that Dean Yu is inactive) or 
> 4 (if Tyler wants to step down) board members.My suggestion would be to elect 
> 2 or 3 board members so that we have a smooth transition from the current 
> state
> Allowing amendments? Do we want to use the meeting on Sep 11 to vote for 
> suggested amendments to the process like it happened in 2015? I would vote 
> for doing so so that all contributors have an opportunity to suggest a change 
> and to integrate it into the final process.
> Please review the above and share your thoughts. Ideally we discuss now with 
> the goal of reaching consensus by the next governance meeting on August 11th 
> when we can finalize/ratify the proposal. 
> 
> I think our main goal is to have a consensus about the elections happening 
> and about the timeline.
> For the technical implementation of the voting system and process we have a 
> bit more time, because the system will be used only on Oct 14.
> It gives us a bit more time to discuss options and to test the voting system 
> (e.g. by voting for a best Jenkins logo or other similar fun tooic? :) ).
> 
> Best regards,
> Oleg
> 
> 
> On Wednesday, September 4, 2019 at 10:38:22 PM UTC+2, Tracy Miranda wrote:
> Hi all, 
> 
> As you may or may not know Jenkins project is run by a Governance Board with 
> support from a set of Officers. 
> 
> While a process has been set out for elections we are overdue an election. 
> With Jenkins moving from SPI to CDF 
>  the timing is good to do 
> this. CD.Foundation is a multi-project foundation with corporate sponsors and 
> various oversight bodies. The nature of the foundation means we need to 
> ensure good channels for communications and a robust operating model. 
> 
> With that in mind I am proposing the following set of dates for running a new 
> elections. The election process will be bootstrapped by the existing board 
> and we will request CDF run and supervise the election using the The 
> Condorcet Internet voting system .
> 
> Please review the proposal below and 

Re: Jenkins Board & Officer Elections 2019

[Oleg Nenashev]

Hi all,

Strong +1 from me for having an election. The board election issue was 
already a really visible issue in 2015 when we had a discussion of the 
board election process. The Board Election Process 
 referenced 
by Tracy was an outcome of months of discussions in the community. The 
process was signed off by the governance meeting though many current key 
contributors were not in the community in 2015. The vote itself has never 
happened due to the voting system implementation issues, but there was a 
strong consensus that we do need an election. In 2019 it is even more 
needed IMHO, just few reasons:

   - The current Jenkins board includes 3 people, but one is completely 
   inactive in the community. So we are down to two, which is a pretty bad bus 
   factor for a project of the Jenkins' size. Kohsuke and Tyler have a lot of 
   commitments in the project and IRL, so having more board members would 
   definitely improve the board's bandwidth
   - Some critical processes in the Jenkins project are either stalled or 
   defunct: regular Governance meetings, JEPs, officer reelections, etc. 
   Having an active Jenkins board is instrumental to reviving these processes
   - Migration to CDF requires a lot of changes in the project: 
   infrastructure and service accounts handover, trademark approval process, 
   etc. It would require extra capacity from the board to coordinate the 
   effort and to get it over the line. Jenkins has joined CDF almost 1 year 
   ago, but there are still A LOT of open questions about the migration to CDF
   - Lack of Technical Steering Committee in Jenkins, it is one of the 
   stories we were originally discussing for "Jenkins Software Foundation" at 
   the at Jenkins World 2017. Having an active Jenkins board would be a 
   precondition to make this steering committee happen. IMHO we desperately 
   need it to work on the Jenkins evolution in the CDF environment where we 
   will need to facilitate contributions from individual contributors and 
   company contributors. A steering committee would be really helpful to make 
   it happen

The proposed schedule is pretty tight assuming that the target Governance 
meeting will happen in Sep 11, but I believe we can make it work if there 
is a consensus. The  Board Election Process 
 defined in 
2015 still looks pretty solid in 2019, so we could start there. I also 
agree with the changes proposed by Tracy.

Some other questions to answer in the discussion:

   - *How many board members do we want to elect?* We are supposed to elect 
   only 2 board members at once, but, If we follow the 2015 process, 2-year 
   terms are long expired. So we can vote for 2, 3 (assuming that Dean Yu is 
   inactive) or 4 (if Tyler wants to step down) board members.My suggestion 
   would be to elect 2 or 3 board members so that we have a smooth transition 
   from the current state
   - *Allowing amendments?* Do we want to use the meeting on Sep 11 to vote 
   for suggested amendments to the process like it happened in 2015? I would 
   vote for doing so so that all contributors have an opportunity to suggest a 
   change and to integrate it into the final process.

Please review the above and share your thoughts. Ideally we discuss now 
> with the goal of reaching consensus by the next governance meeting on 
> August 11th when we can finalize/ratify the proposal. 
>

I think our main goal is to have a consensus about the elections happening 
and about the timeline.
For the technical implementation of the voting system and process we have a 
bit more time, because the system will be used only on Oct 14.
It gives us a bit more time to discuss options and to test the voting 
system (e.g. by voting for a best Jenkins logo or other similar fun tooic? 
:) ).

Best regards,
Oleg


On Wednesday, September 4, 2019 at 10:38:22 PM UTC+2, Tracy Miranda wrote:
>
> Hi all, 
>
> As you may or may not know Jenkins project is run by a Governance Board 
> with support from a set of Officers. 
>
> While a process has been set out for elections we are overdue an election. 
> With Jenkins moving from SPI to CDF 
>  the timing is good to do 
> this. CD.Foundation is a multi-project foundation with corporate sponsors 
> and various oversight bodies. The nature of the foundation means we need to 
> ensure good channels for communications and a robust operating model. 
>
> With that in mind I am proposing the following set of dates for running a 
> new elections. The election process will be bootstrapped by the existing 
> board and we will request CDF run and supervise the election using the The 
> Condorcet Internet voting system .
>
> Please review the proposal below and links outlining the process for new 
> board and officer elections. 
>
> 2019 Election 

Re: [DISCUSS] Default assignee on new plugin JIRA issues (was: Re: Request to be made maintainer of ant-plugin)

[Ullrich Hafner]

Making it an optional field in the HOSTING report seems to be a good 
compromise, so +1 from me for such a change.

(I understand that developers do not want to be assignee for issues they are 
never going to fix. On the other hands, for a user that reports an issue it is 
somewhat disappointing that no one actually cares about his new issue. This 
will indicate that it is not worth to report an issue at all.)
 

> Am 05.09.2019 um 20:40 schrieb Slide :
> 
> We should add a field in the HOSTING Jira that allows people to specify if 
> they want to be set as the default assignee, then the bot can check that 
> field before setting up the default assignee for the component. We would need 
> someone with admin access on Jira to add the field. I can create a PR for the 
> bot once the field is setup.
> 
> On Thu, Sep 5, 2019, 11:35 Matt Sicker  > wrote:
> That makes tons of sense to me. You should only assign tickets to
> yourself that you're currently working on or at least intend to work
> on in the near future.
> 
> On Thu, Sep 5, 2019 at 4:31 AM Baptiste Mathus  > wrote:
> >
> > I fully agree with Jesse's take. IMO for most plugins where the maintainer 
> > is not going to have time to jump on new reports right away, this sends a 
> > wrong message that issues will be analyzed and fixed by the assignee.
> > This sends a second bad message: that an issue being already assigned, this 
> > is not necessary that someone steps up to work on a fix proposal.
> >
> > AIUI, the default assignee is often used by maintainers as a nice way to be 
> > notified when a new issue arises, but on average not meaning that that 
> > given maintainer will commit to address in a timely manner anything new 
> > that comes in.
> >
> > IOW, my main point is that I think we should allow maintainers to be made 
> > default assignee, but we should default to having no default assignee.
> >
> > Le mar. 27 août 2019 à 15:14, Jesse Glick  > > a écrit :
> >>
> >> On Tue, Aug 27, 2019 at 8:54 AM Oleg Nenashev  >> > wrote:
> >> > a default assignee for the component
> >>
> >> As always, I prefer there to be no default assignee for a JIRA
> >> component. It is not a helpful concept IMO. If and when I decide to
> >> tackle an issue, I will assign it to myself.
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups 
> >> "Jenkins Developers" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an 
> >> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> >> .
> >> To view this discussion on the web visit 
> >> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2MLHtwCNgQhbLCBjV78NVPSCUs0zUs2_zDChw6Aad5bw%40mail.gmail.com
> >>  
> >> .
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Jenkins Developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to jenkinsci-dev+unsubscr...@googlegroups.com 
> > .
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7J1661hacPVP9rMN5sK%2Bz_Hsos28Bd8N%2BNbxwxMouWNA%40mail.gmail.com
> >  
> > .
> 
> 
> 
> -- 
> Matt Sicker
> Senior Software Engineer, CloudBees
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4ox7Xqp9gzdht-R7GYHjs%2B%3DUdw2Yk32H91pnvyUw9axRZw%40mail.gmail.com
>  
> .
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVduNcw%3DWYb6%2BHNebzarAoQCt%2Bg6bQuFgitVP%3DuC3O2Bww%40mail.gmail.com
>  
> .

-- 
You received this message because you are subscribed to the 

Re: [DISCUSS] Default assignee on new plugin JIRA issues (was: Re: Request to be made maintainer of ant-plugin)

[Jesse Glick]

On Thu, Sep 5, 2019 at 2:36 PM Gavin  wrote:
> Does jira have a concept of auto watch like GitHub does? So an issue could 
> still notify people but not be claimed?

Good question. That would be very useful.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3SkUwcr4D4mDfqgF2axjWFv42J-2_zRcBgF%2BNOXsK%3DLQ%40mail.gmail.com.

Re: [DISCUSS] Default assignee on new plugin JIRA issues (was: Re: Request to be made maintainer of ant-plugin)

[Gavin]

Does jira have a concept of auto watch like GitHub does? So an issue could
still notify people but not be claimed?

On Thu., Sep. 5, 2019, 11:35 a.m. Matt Sicker, 
wrote:

> That makes tons of sense to me. You should only assign tickets to
> yourself that you're currently working on or at least intend to work
> on in the near future.
>
> On Thu, Sep 5, 2019 at 4:31 AM Baptiste Mathus  wrote:
> >
> > I fully agree with Jesse's take. IMO for most plugins where the
> maintainer is not going to have time to jump on new reports right away,
> this sends a wrong message that issues will be analyzed and fixed by the
> assignee.
> > This sends a second bad message: that an issue being already assigned,
> this is not necessary that someone steps up to work on a fix proposal.
> >
> > AIUI, the default assignee is often used by maintainers as a nice way to
> be notified when a new issue arises, but on average not meaning that that
> given maintainer will commit to address in a timely manner anything new
> that comes in.
> >
> > IOW, my main point is that I think we should allow maintainers to be
> made default assignee, but we should default to having no default assignee.
> >
> > Le mar. 27 août 2019 à 15:14, Jesse Glick  a
> écrit :
> >>
> >> On Tue, Aug 27, 2019 at 8:54 AM Oleg Nenashev 
> wrote:
> >> > a default assignee for the component
> >>
> >> As always, I prefer there to be no default assignee for a JIRA
> >> component. It is not a helpful concept IMO. If and when I decide to
> >> tackle an issue, I will assign it to myself.
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
> >> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2MLHtwCNgQhbLCBjV78NVPSCUs0zUs2_zDChw6Aad5bw%40mail.gmail.com
> .
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7J1661hacPVP9rMN5sK%2Bz_Hsos28Bd8N%2BNbxwxMouWNA%40mail.gmail.com
> .
>
>
>
> --
> Matt Sicker
> Senior Software Engineer, CloudBees
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4ox7Xqp9gzdht-R7GYHjs%2B%3DUdw2Yk32H91pnvyUw9axRZw%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DuvBB0ye4y%2Bg2_F8MjwgbMPutgUbuiFTA0d0fjVnYX4xcw%40mail.gmail.com.

Re: [DISCUSS] Default assignee on new plugin JIRA issues (was: Re: Request to be made maintainer of ant-plugin)

[Matt Sicker]

That makes tons of sense to me. You should only assign tickets to
yourself that you're currently working on or at least intend to work
on in the near future.

On Thu, Sep 5, 2019 at 4:31 AM Baptiste Mathus  wrote:
>
> I fully agree with Jesse's take. IMO for most plugins where the maintainer is 
> not going to have time to jump on new reports right away, this sends a wrong 
> message that issues will be analyzed and fixed by the assignee.
> This sends a second bad message: that an issue being already assigned, this 
> is not necessary that someone steps up to work on a fix proposal.
>
> AIUI, the default assignee is often used by maintainers as a nice way to be 
> notified when a new issue arises, but on average not meaning that that given 
> maintainer will commit to address in a timely manner anything new that comes 
> in.
>
> IOW, my main point is that I think we should allow maintainers to be made 
> default assignee, but we should default to having no default assignee.
>
> Le mar. 27 août 2019 à 15:14, Jesse Glick  a écrit :
>>
>> On Tue, Aug 27, 2019 at 8:54 AM Oleg Nenashev  wrote:
>> > a default assignee for the component
>>
>> As always, I prefer there to be no default assignee for a JIRA
>> component. It is not a helpful concept IMO. If and when I decide to
>> tackle an issue, I will assign it to myself.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2MLHtwCNgQhbLCBjV78NVPSCUs0zUs2_zDChw6Aad5bw%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7J1661hacPVP9rMN5sK%2Bz_Hsos28Bd8N%2BNbxwxMouWNA%40mail.gmail.com.



-- 
Matt Sicker
Senior Software Engineer, CloudBees

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4ox7Xqp9gzdht-R7GYHjs%2B%3DUdw2Yk32H91pnvyUw9axRZw%40mail.gmail.com.

Re: google-kubernetes-engine-plugin repo (re-add team plz)

['Craig Barber' via Jenkins Developers]

Thanks Baptiste!

I don't have the permissions to add/remove members from that team. Is that
a perm you'd be able to grant my account?

On Thu, Sep 5, 2019 at 3:14 AM Baptiste Mathus  wrote:

> Done, also have taken this as an opportunity to remove people from
> "Collaborators" part, assuming all people should be in the team (and if
> not, need to be added there).
>
> Please confirm this is now OK.
>
> Cheers!
>
> Le mer. 4 sept. 2019 à 23:11, 'Craig Barber' via Jenkins Developers <
> jenkinsci-dev@googlegroups.com> a écrit :
>
>> Hello,
>>
>> The team
>> https://github.com/orgs/jenkinsci/teams/google-kubernetes-engine-plugin-developers
>>  was
>> accidently deleted from the collaborators for the repo:
>> https://github.com/jenkinsci/google-kubernetes-engine-plugin
>>
>> Could someone with proper org permissions please re-add the team as Admin
>> to the project. Thank you.
>>
>> --
>> Craig Barber
>> Software Engineer
>> Cloud Graphite: Platforms
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CANO%2BKbUoW8uK1mRP%2BVJPEP1aAbMrA%2BExmLchM3-vrmtXPzkiDw%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4PQYkaEVu7YTQFfuj0s9U5YhjuRS_9M-YZQJct1oYchw%40mail.gmail.com
> 
> .
>


-- 
Craig Barber
Software Engineer
Cloud Graphite: Platforms

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANO%2BKbX4ZC9A2tUjdx4XnsWhO3ZRHhq-JdaN%3DcZ0njgq%2Bp7sHw%40mail.gmail.com.

Re: Backporting for LTS 2.190.1 started

[Raul Arabaolaza]

I believe the security fixes are not yet backported, or I am doing 
something wrong on my personal merges :)

Regards

On Thursday, September 5, 2019 at 1:28:26 PM UTC+2, Daniel Beck wrote:
>
> I cleaned up the candidates so nothing that was merged into 2.190 or 
> earlier is listed -- the list is quite a bit shorter now! The 'fix version' 
> field helped a lot :-) 
>
> Please remember to backport the security fixes from 2.192. AFAICT it's the 
> first time in years that we decided on a baseline predating the previous 
> LTS's ".3" security fixes. 
>
>
> > On 2. Sep 2019, at 10:31, Oliver Gondža > 
> wrote: 
> > 
> > Backporting has started and the RC is scheduled for 2019-09-11. 
> > 
> > Candidates: https://issues.jenkins-ci.org/issues/?filter=12146 
> > Fixed: 
> https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.190.1-fixed 
> > Rejected: 
> https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.190.1-rejected 
> > -- 
> > oliver 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "Jenkins Developers" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to jenkin...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/dc475718-9f3b-6c5d-c467-f6812b154cb1%40gmail.com.
>  
>
> > 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/2f1f2650-b8be-4969-ad06-792c0b5a2d62%40googlegroups.com.

Re: Backporting for LTS 2.190.1 started

[Daniel Beck]

I cleaned up the candidates so nothing that was merged into 2.190 or earlier is 
listed -- the list is quite a bit shorter now! The 'fix version' field helped a 
lot :-)

Please remember to backport the security fixes from 2.192. AFAICT it's the 
first time in years that we decided on a baseline predating the previous LTS's 
".3" security fixes.


> On 2. Sep 2019, at 10:31, Oliver Gondža  wrote:
> 
> Backporting has started and the RC is scheduled for 2019-09-11.
> 
> Candidates: https://issues.jenkins-ci.org/issues/?filter=12146
> Fixed: https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.190.1-fixed
> Rejected: 
> https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.190.1-rejected
> -- 
> oliver
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/dc475718-9f3b-6c5d-c467-f6812b154cb1%40gmail.com.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/40F773DF-C170-41E5-81C6-C9C45B0608EC%40beckweb.net.

Re: google-kubernetes-engine-plugin repo (re-add team plz)

[Baptiste Mathus]

Done, also have taken this as an opportunity to remove people from
"Collaborators" part, assuming all people should be in the team (and if
not, need to be added there).

Please confirm this is now OK.

Cheers!

Le mer. 4 sept. 2019 à 23:11, 'Craig Barber' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> a écrit :

> Hello,
>
> The team
> https://github.com/orgs/jenkinsci/teams/google-kubernetes-engine-plugin-developers
>  was
> accidently deleted from the collaborators for the repo:
> https://github.com/jenkinsci/google-kubernetes-engine-plugin
>
> Could someone with proper org permissions please re-add the team as Admin
> to the project. Thank you.
>
> --
> Craig Barber
> Software Engineer
> Cloud Graphite: Platforms
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANO%2BKbUoW8uK1mRP%2BVJPEP1aAbMrA%2BExmLchM3-vrmtXPzkiDw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4PQYkaEVu7YTQFfuj0s9U5YhjuRS_9M-YZQJct1oYchw%40mail.gmail.com.

Re: Maintainer for webhook-step-plugin

[Baptiste Mathus]

Please proceed indeed. Timeout is expired, so +1 as Gavin is saying. Thanks
a lot Alex!

Le mar. 3 sept. 2019 à 20:56, Slide  a écrit :

> There has been no response from the maintainer for longer than the 2 week
> timeout period we normally have. Any -1's on this or can I proceed?
>
> On Tue, Jul 16, 2019 at 8:41 AM Slide  wrote:
>
>> I wanted to propose myself being added as a maintainer to the
>> webhook-step-plugin. There are some PR's that would be good to merge that
>> have been around for some time. I am using this plugin at work and would
>> like to get those PR's merged into a formal release (I am using a
>> self-built version right now).
>>
>> I CC'd the maintainer on this email. The plugin is not currently up for
>> adoption, but there has not been a release in some time.(Last release Oct
>> 17, 2017).
>>
>> Thanks,
>>
>> Alex
>>
>> --
>> Website: http://earl-of-code.com
>>
>
>
> --
> Website: http://earl-of-code.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVebdtv6%2BWJ7p%2BtT022iN%3DdravNzWV4EdfH3gu11Xk0gpA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS48h%2BT9ySsukss5qS-eXM-QKGtgeV838uzgdXK%3DqHcK8Q%40mail.gmail.com.

Re: Hosting process

[Baptiste Mathus]

I am +1000 on the transfer goal, instead of forking.

I am quite bothered TBH by the immense amount of fork links that are still
present on many (most?) plugins in our GH org. I believe that it sends
quite a misleading message especially to new contributors.

We indeed need to be very careful and automate ideally everything, because
to be allowed to transfer repo, AFAIR one needs to be admin. And in the
past, we've had someone even *delete* the
https://github.com/jenkinsci-transfer organization after the transfer had
been done, thinking this was a one-off one...

On top of the fact PRs against forked repositories are simply ignored in
one's statistics (granted, not everybody cares about this, but I think this
can be important for some people, possibly more juniors, who want to join
the pleasant and the useful to grow their résumé).

Le jeu. 29 août 2019 à 11:48, Oleg Nenashev  a
écrit :

> As long as the transfer process is automated, +100 for that.
> It should also help to avoid issues when contributor companies request
> hosting but then continue development in their own repos (no
> finger-pointing in this thread).
>
> On Wednesday, August 28, 2019 at 8:58:13 PM UTC+2, Gavin Mogan wrote:
>>
>> > Which would be a downside I think.
>>
>> Oh I thought that was the intention
>>
>> Yea for sure a downside
>>
>> On Wed, Aug 28, 2019 at 11:56 AM Jesse Glick 
>> wrote:
>>
>>> On Wed, Aug 28, 2019 at 12:31 PM 'Gavin Mogan' via Jenkins Developers
>>>  wrote:
>>> > That would break the fork linkage
>>>
>>> Which would be a downside I think. Also the current method forces you
>>> to remember to delete your own account’s clone so the @jenkinsci one
>>> does not appear as a fork of it.
>>>
>>> Also you would lose any existing issues, PRs, etc.
>>>
>>> The repository transfer operation seems like the most intuitive and
>>> least problematic approach.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkin...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1_d16DVnis%3DQRpZa5R%3D_VXaw94pr%2BCLyHL%2BuBz%3DF64bw%40mail.gmail.com
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/cc66f864-4acc-4cc0-b79f-71d918f3fe37%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6dOhyxLosHF78nGcas27okKPx2tjjno-E-5iYJ-M3Thw%40mail.gmail.com.

[DISCUSS] Default assignee on new plugin JIRA issues (was: Re: Request to be made maintainer of ant-plugin)

[Baptiste Mathus]

I fully agree with Jesse's take. IMO for most plugins where the maintainer
is not going to have time to jump on new reports right away, this sends a
wrong message that issues will be analyzed and fixed by the assignee.
This sends a second bad message: that an issue being already assigned, this
is not necessary that someone steps up to work on a fix proposal.

AIUI, the default assignee is often used by maintainers as a nice way to be
notified when a new issue arises, but on average not meaning that that
given maintainer will commit to address in a timely manner anything new
that comes in.

IOW, my main point is that I think we should allow maintainers to be made
default assignee, but we should default to having no default assignee.

Le mar. 27 août 2019 à 15:14, Jesse Glick  a écrit :

> On Tue, Aug 27, 2019 at 8:54 AM Oleg Nenashev 
> wrote:
> > a default assignee for the component
>
> As always, I prefer there to be no default assignee for a JIRA
> component. It is not a helpful concept IMO. If and when I decide to
> tackle an issue, I will assign it to myself.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2MLHtwCNgQhbLCBjV78NVPSCUs0zUs2_zDChw6Aad5bw%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7J1661hacPVP9rMN5sK%2Bz_Hsos28Bd8N%2BNbxwxMouWNA%40mail.gmail.com.