Re: New proposal for Ubuntu Backporters Team Charter
On Wed, Jun 07, 2023 at 05:35:21PM +0200, Mattia Rizzolo wrote: > Today we had a Backporters meeting, and indeed we don't have any > opposition to this latest proposal, thank you for the prods, and I'm > happy that this topic is finally coming to a close! Thanks! > Please do email us a bit more "formally" once it's done, so that we have > a good authoritative reference to link to later on :) Consider this the formal email then please? > I think following this ratification the next question would be: where is > a good place to collect them? Personally I'm going to copy it under > our "wiki space" (and perhaps under launchpad as well? It's short > enough…), but the final goal was for the TB to define a bunch of > these for all the other interesting teams too, so I wonder if you > already have something good in mind? I've documented this at https://wiki.ubuntu.com/TechnicalBoard#Backporters_Team for now. As it grows, it could move to its own page. Robie signature.asc Description: PGP signature -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
Re: New proposal for Ubuntu Backporters Team Charter
So, hello TB! Today we had a Backporters meeting, and indeed we don't have any opposition to this latest proposal, thank you for the prods, and I'm happy that this topic is finally coming to a close! Please do email us a bit more "formally" once it's done, so that we have a good authoritative reference to link to later on :) I think following this ratification the next question would be: where is a good place to collect them? Personally I'm going to copy it under our "wiki space" (and perhaps under launchpad as well? It's short enough…), but the final goal was for the TB to define a bunch of these for all the other interesting teams too, so I wonder if you already have something good in mind? On Wed, May 31, 2023 at 04:45:35AM +0930, Alex Murray wrote: > Hi backporters team, > > The TB has still not received any response on the proposal to adopt > Mattia's suggested Charter. As such, in today's TB meeting it was agreed > that the TB would ratify this as the Charter for the Backporters team > after Monday 12th June. Please let us know if you have objections to > this proposal before that date. > > Thanks, > Alex > > On Tue, 2023-05-23 at 18:30:12 +0930, Alex Murray wrote: > > > Hey backporters team, > > > > Just wanted to see if anyone had any thoughts on this? The TB are keen > > to move this forward and are just waiting on some kind of ACK from your > > side. > > > > Thanks, > > Alex > > > > On Tue, 2023-05-09 at 14:59:22 +0930, Alex Murray wrote: > > > >> Hi folks, > >> > >> After the most recent Tech Board meeting, the TB agreed that the best > >> way forward here would be to go with Mattia's proposal outlined below (I > >> have reproduced it here): > >> > >> * Maintain the Ubuntu "backports" pocket. > >> * Establish and manage an effective process and a set of policies to > >> handle contributions to the "backports" pocket. > >> * Define a set of rules to handle the Backports Team memberships, its > >> internal structure and members' responsbilities. > >> > >> Would the Backporters Team be willing to adopt this as their Charter? > >> > >> Thanks, > >> Alex > >> > >> > >> On Wed, 2023-03-01 at 16:22:13 +0100, Mattia Rizzolo wrote: > >> > >>> On Wed, Mar 01, 2023 at 11:03:02AM +1030, Alex Murray wrote: > Just wondering if you had a chance to review my feedback? It would be > great to try and make some progress here. > >>> > >>> We have a meeting later today, but I'll give you my own inputs. > >>> > >>> The tl;dr: I'm more in-line with Dan comments. > >>> > >>> * Establish and manage an effective process to handle backport > >>>requests based solely on their technical merit. > >> > >> I'm not sure this is correct, to handle requests *solely* on technical > >> merit. For example, part of the backport process is the expectation > >> that the backport requestor/uploader will remain responsible for > >> further backports as needed; if an uploaded backport seems technically > >> correct but the backports team does not believe the uploader would be > >> responsible for further uploads, the backports team should be able to > >> reject the upload on that basis. > >> > >> Stating "solely on their technical merit" places undue restrictions on > >> our team, I believe. > >> > > > > I feel it is perhaps a bit too onerous to expect that just because a > > user contributes one backport that they then should be expected to keep > > doing backports for that package - this is placing undue restrictions > > on > > your possible contributors. Regardless though, I don't think the > > backports team should be trying to guess whether someone is likely to > > contribute further backports in the future - this leaves too much > > chance > > for the team to ignore proposed backports on arbitrary grounds. As > > such, > > this is the exact point of the statement "solely on their technical > > merit" - to give confidence to prospective users who want to contribute > > backports that their submissions will be treated in a fair manner. > >>> > >>> I'm sorry, but I do have and want to have some expectations that nobody > >>> does *1* drive-by contribution and upload, and then the package is left > >>> to bitrot in the backports pocket forevermore. Really, if that was > >>> their goal, they are better served by a PPA. > >>> > >>> We are clearly not enforcing this at this time, but I don't want to > >>> restrict us. > >>> > >>> From my own side, I'd propose this sentence instead: > >>> > >>> * Establish and manage an effective process and a set of policies to > >>> handle contributions to the "backports" pocket. > >>> > >>> * Maintain the backports pocket based on this process, with an aim > >>> to > >>>ensure all requests are responded to in a reasonable amount of > >>> time. > >> > >> What does "reasonable
Re: New proposal for Ubuntu Backporters Team Charter
Hi backporters team, The TB has still not received any response on the proposal to adopt Mattia's suggested Charter. As such, in today's TB meeting it was agreed that the TB would ratify this as the Charter for the Backporters team after Monday 12th June. Please let us know if you have objections to this proposal before that date. Thanks, Alex On Tue, 2023-05-23 at 18:30:12 +0930, Alex Murray wrote: > Hey backporters team, > > Just wanted to see if anyone had any thoughts on this? The TB are keen > to move this forward and are just waiting on some kind of ACK from your > side. > > Thanks, > Alex > > On Tue, 2023-05-09 at 14:59:22 +0930, Alex Murray wrote: > >> Hi folks, >> >> After the most recent Tech Board meeting, the TB agreed that the best >> way forward here would be to go with Mattia's proposal outlined below (I >> have reproduced it here): >> >> * Maintain the Ubuntu "backports" pocket. >> * Establish and manage an effective process and a set of policies to >> handle contributions to the "backports" pocket. >> * Define a set of rules to handle the Backports Team memberships, its >> internal structure and members' responsbilities. >> >> Would the Backporters Team be willing to adopt this as their Charter? >> >> Thanks, >> Alex >> >> >> On Wed, 2023-03-01 at 16:22:13 +0100, Mattia Rizzolo wrote: >> >>> On Wed, Mar 01, 2023 at 11:03:02AM +1030, Alex Murray wrote: Just wondering if you had a chance to review my feedback? It would be great to try and make some progress here. >>> >>> We have a meeting later today, but I'll give you my own inputs. >>> >>> The tl;dr: I'm more in-line with Dan comments. >>> >>> * Establish and manage an effective process to handle backport >>>requests based solely on their technical merit. >> >> I'm not sure this is correct, to handle requests *solely* on technical >> merit. For example, part of the backport process is the expectation >> that the backport requestor/uploader will remain responsible for >> further backports as needed; if an uploaded backport seems technically >> correct but the backports team does not believe the uploader would be >> responsible for further uploads, the backports team should be able to >> reject the upload on that basis. >> >> Stating "solely on their technical merit" places undue restrictions on >> our team, I believe. >> > > I feel it is perhaps a bit too onerous to expect that just because a > user contributes one backport that they then should be expected to keep > doing backports for that package - this is placing undue restrictions on > your possible contributors. Regardless though, I don't think the > backports team should be trying to guess whether someone is likely to > contribute further backports in the future - this leaves too much chance > for the team to ignore proposed backports on arbitrary grounds. As such, > this is the exact point of the statement "solely on their technical > merit" - to give confidence to prospective users who want to contribute > backports that their submissions will be treated in a fair manner. >>> >>> I'm sorry, but I do have and want to have some expectations that nobody >>> does *1* drive-by contribution and upload, and then the package is left >>> to bitrot in the backports pocket forevermore. Really, if that was >>> their goal, they are better served by a PPA. >>> >>> We are clearly not enforcing this at this time, but I don't want to >>> restrict us. >>> >>> From my own side, I'd propose this sentence instead: >>> >>> * Establish and manage an effective process and a set of policies to >>> handle contributions to the "backports" pocket. >>> >>> * Maintain the backports pocket based on this process, with an aim to >>>ensure all requests are responded to in a reasonable amount of time. >> >> What does "reasonable amount of time" mean? >> > > This is purposely non-specific - but again is here to give prospective > users confidence that their submissions will not sit ignored for an > indefinite period. >>> >>> Too little specificity is not good. I'm not sure what's best (to write >>> down an arbitrary timeframe or what else), but having this sentence so >>> meaningless is worse than not having it, for me. >>> >>> Potentially, I'd be more open to have a SLA-like rule in our internal >>> policies. >>> >>> * Maintain quality in the backports pocket, where the definition of >>>quality is driven by the team, but decided by consensus within the >>>wider Ubuntu developer community. >> >> I'm not quite sure what this statement is trying to achieve, or what >> it would mean in practice. Can you clarify? >> > > This allows the backports team to take the lead on defining what is > required in terms of quality for submissions but also allows
Re: New proposal for Ubuntu Backporters Team Charter
Hey backporters team, Just wanted to see if anyone had any thoughts on this? The TB are keen to move this forward and are just waiting on some kind of ACK from your side. Thanks, Alex On Tue, 2023-05-09 at 14:59:22 +0930, Alex Murray wrote: > Hi folks, > > After the most recent Tech Board meeting, the TB agreed that the best > way forward here would be to go with Mattia's proposal outlined below (I > have reproduced it here): > > * Maintain the Ubuntu "backports" pocket. > * Establish and manage an effective process and a set of policies to > handle contributions to the "backports" pocket. > * Define a set of rules to handle the Backports Team memberships, its > internal structure and members' responsbilities. > > Would the Backporters Team be willing to adopt this as their Charter? > > Thanks, > Alex > > > On Wed, 2023-03-01 at 16:22:13 +0100, Mattia Rizzolo wrote: > >> On Wed, Mar 01, 2023 at 11:03:02AM +1030, Alex Murray wrote: >>> Just wondering if you had a chance to review my feedback? It would be >>> great to try and make some progress here. >> >> We have a meeting later today, but I'll give you my own inputs. >> >> The tl;dr: I'm more in-line with Dan comments. >> >>> >>> * Establish and manage an effective process to handle backport >>> >>>requests based solely on their technical merit. >>> >> >>> >> I'm not sure this is correct, to handle requests *solely* on technical >>> >> merit. For example, part of the backport process is the expectation >>> >> that the backport requestor/uploader will remain responsible for >>> >> further backports as needed; if an uploaded backport seems technically >>> >> correct but the backports team does not believe the uploader would be >>> >> responsible for further uploads, the backports team should be able to >>> >> reject the upload on that basis. >>> >> >>> >> Stating "solely on their technical merit" places undue restrictions on >>> >> our team, I believe. >>> >> >>> > >>> > I feel it is perhaps a bit too onerous to expect that just because a >>> > user contributes one backport that they then should be expected to keep >>> > doing backports for that package - this is placing undue restrictions on >>> > your possible contributors. Regardless though, I don't think the >>> > backports team should be trying to guess whether someone is likely to >>> > contribute further backports in the future - this leaves too much chance >>> > for the team to ignore proposed backports on arbitrary grounds. As such, >>> > this is the exact point of the statement "solely on their technical >>> > merit" - to give confidence to prospective users who want to contribute >>> > backports that their submissions will be treated in a fair manner. >> >> I'm sorry, but I do have and want to have some expectations that nobody >> does *1* drive-by contribution and upload, and then the package is left >> to bitrot in the backports pocket forevermore. Really, if that was >> their goal, they are better served by a PPA. >> >> We are clearly not enforcing this at this time, but I don't want to >> restrict us. >> >> From my own side, I'd propose this sentence instead: >> >> * Establish and manage an effective process and a set of policies to >> handle contributions to the "backports" pocket. >> >>> >>> * Maintain the backports pocket based on this process, with an aim to >>> >>>ensure all requests are responded to in a reasonable amount of time. >>> >> >>> >> What does "reasonable amount of time" mean? >>> >> >>> > >>> > This is purposely non-specific - but again is here to give prospective >>> > users confidence that their submissions will not sit ignored for an >>> > indefinite period. >> >> Too little specificity is not good. I'm not sure what's best (to write >> down an arbitrary timeframe or what else), but having this sentence so >> meaningless is worse than not having it, for me. >> >> Potentially, I'd be more open to have a SLA-like rule in our internal >> policies. >> >>> >>> * Maintain quality in the backports pocket, where the definition of >>> >>>quality is driven by the team, but decided by consensus within the >>> >>>wider Ubuntu developer community. >>> >> >>> >> I'm not quite sure what this statement is trying to achieve, or what >>> >> it would mean in practice. Can you clarify? >>> >> >>> > >>> > This allows the backports team to take the lead on defining what is >>> > required in terms of quality for submissions but also allows the >>> > community to give feedback / input as well. >> >> I'd drop this. Or at worse add a couple of words in the first point >> about us defining policies. >> >>> >>> * Handle process reform and membership management internally, ensuring >>> >>>that any responsibility can be carried by any contributor who >>> >>>demonstrates the required capacity and competence. >>> >> >>> >> I think this statement is even harder to read, can you clarify and/or >>> >> reword it? >>> >> >>> >> For example, if we must
Re: New proposal for Ubuntu Backporters Team Charter
Hi folks, After the most recent Tech Board meeting, the TB agreed that the best way forward here would be to go with Mattia's proposal outlined below (I have reproduced it here): * Maintain the Ubuntu "backports" pocket. * Establish and manage an effective process and a set of policies to handle contributions to the "backports" pocket. * Define a set of rules to handle the Backports Team memberships, its internal structure and members' responsbilities. Would the Backporters Team be willing to adopt this as their Charter? Thanks, Alex On Wed, 2023-03-01 at 16:22:13 +0100, Mattia Rizzolo wrote: > On Wed, Mar 01, 2023 at 11:03:02AM +1030, Alex Murray wrote: >> Just wondering if you had a chance to review my feedback? It would be >> great to try and make some progress here. > > We have a meeting later today, but I'll give you my own inputs. > > The tl;dr: I'm more in-line with Dan comments. > >> >>> * Establish and manage an effective process to handle backport >> >>>requests based solely on their technical merit. >> >> >> >> I'm not sure this is correct, to handle requests *solely* on technical >> >> merit. For example, part of the backport process is the expectation >> >> that the backport requestor/uploader will remain responsible for >> >> further backports as needed; if an uploaded backport seems technically >> >> correct but the backports team does not believe the uploader would be >> >> responsible for further uploads, the backports team should be able to >> >> reject the upload on that basis. >> >> >> >> Stating "solely on their technical merit" places undue restrictions on >> >> our team, I believe. >> >> >> > >> > I feel it is perhaps a bit too onerous to expect that just because a >> > user contributes one backport that they then should be expected to keep >> > doing backports for that package - this is placing undue restrictions on >> > your possible contributors. Regardless though, I don't think the >> > backports team should be trying to guess whether someone is likely to >> > contribute further backports in the future - this leaves too much chance >> > for the team to ignore proposed backports on arbitrary grounds. As such, >> > this is the exact point of the statement "solely on their technical >> > merit" - to give confidence to prospective users who want to contribute >> > backports that their submissions will be treated in a fair manner. > > I'm sorry, but I do have and want to have some expectations that nobody > does *1* drive-by contribution and upload, and then the package is left > to bitrot in the backports pocket forevermore. Really, if that was > their goal, they are better served by a PPA. > > We are clearly not enforcing this at this time, but I don't want to > restrict us. > > From my own side, I'd propose this sentence instead: > > * Establish and manage an effective process and a set of policies to > handle contributions to the "backports" pocket. > >> >>> * Maintain the backports pocket based on this process, with an aim to >> >>>ensure all requests are responded to in a reasonable amount of time. >> >> >> >> What does "reasonable amount of time" mean? >> >> >> > >> > This is purposely non-specific - but again is here to give prospective >> > users confidence that their submissions will not sit ignored for an >> > indefinite period. > > Too little specificity is not good. I'm not sure what's best (to write > down an arbitrary timeframe or what else), but having this sentence so > meaningless is worse than not having it, for me. > > Potentially, I'd be more open to have a SLA-like rule in our internal > policies. > >> >>> * Maintain quality in the backports pocket, where the definition of >> >>>quality is driven by the team, but decided by consensus within the >> >>>wider Ubuntu developer community. >> >> >> >> I'm not quite sure what this statement is trying to achieve, or what >> >> it would mean in practice. Can you clarify? >> >> >> > >> > This allows the backports team to take the lead on defining what is >> > required in terms of quality for submissions but also allows the >> > community to give feedback / input as well. > > I'd drop this. Or at worse add a couple of words in the first point > about us defining policies. > >> >>> * Handle process reform and membership management internally, ensuring >> >>>that any responsibility can be carried by any contributor who >> >>>demonstrates the required capacity and competence. >> >> >> >> I think this statement is even harder to read, can you clarify and/or >> >> reword it? >> >> >> >> For example, if we must handle process/membership "internally", does >> >> that mean we can't get outside input on those subjects? If not, then >> >> what is the point of the statement at all? >> >> >> > >> > This delegates authority to the backports team for these functions but >> > again makes a statement that hopefully gives prospective contributors >> > confidence that they can
Re: New proposal for Ubuntu Backporters Team Charter
On Wed, 2023-03-01 at 21:33:09 +0100, Mattia Rizzolo wrote: > Hello Robie! > > On Wed, Mar 01, 2023 at 05:21:10PM +, Robie Basak wrote: >> I wonder if it's worth first discussing what the text would actually be >> used *for*, since your reply suggests to me that we might not have the >> same view on this here. > > This seems to be the case indeed. > >> I see the (my) proposed text as a point of reference between the >> backporters team and the rest of the project, but generally only for use >> to guide the backporters team in defining their own policies, procedures >> and documentation, cases where it was unclear what their >> responsibilities are, or in case of some kind of unhappiness > > I think we are in complete agreement then. Mattia, I assume you mean 'in complete agreement' regarding the purpose of the charter and policies - or do you also mean you are in agreement with Robie's proposed text? I am guessing you only mean the former but it would be good to clarify. > Your description perfectly matches my definition as well. > > To me, Charter and Polices are to be the actual rules that describe > how the team has to behave. > Indeed, team members needs to be aware of them, and so do those who > aspire to actually be part of the team. But people who interact with > us (i.e. those contributing backported packages) really have no > business with these documents. So in this case, we are looking at the Charter alone, which I agree should only codify the guiding principles of the team. As such, I think your (Mattia's) suggestion (quoted below) is probably about right. The other details regarding what contributors should expect etc should then be left to the processes / policies to be defined by the team. > * Maintain the Ubuntu "backports" pocket. > * Establish and manage an effective process and a set of policies to > handle contributions to the "backports" pocket. > * Define a set of rules to handle the Backports Team memberships, its > internal structure and members' responsibilities. > > -- > regards, > Mattia Rizzolo > > GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. > More about me: https://mapreri.org : :' : > Launchpad user: https://launchpad.net/~mapreri `. `'` > Debian QA page: https://qa.debian.org/developer.php?login=mattia `- > -- > technical-board mailing list > technical-bo...@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/technical-board -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
Re: New proposal for Ubuntu Backporters Team Charter
Hello Robie! On Wed, Mar 01, 2023 at 05:21:10PM +, Robie Basak wrote: > I wonder if it's worth first discussing what the text would actually be > used *for*, since your reply suggests to me that we might not have the > same view on this here. This seems to be the case indeed. > I see the (my) proposed text as a point of reference between the > backporters team and the rest of the project, but generally only for use > to guide the backporters team in defining their own policies, procedures > and documentation, cases where it was unclear what their > responsibilities are, or in case of some kind of unhappiness I think we are in complete agreement then. Your description perfectly matches my definition as well. To me, Charter and Polices are to be the actual rules that describe how the team has to behave. Indeed, team members needs to be aware of them, and so do those who aspire to actually be part of the team. But people who interact with us (i.e. those contributing backported packages) really have no business with these documents. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
Re: New proposal for Ubuntu Backporters Team Charter
Hi! Thank you for your time on this. On Wed, Mar 01, 2023 at 04:22:13PM +0100, Mattia Rizzolo wrote: > > > So I think we are starting to get to the crux of the difference in > > > viewpoints from the TB to the backporters team. Due to the past history > > > of some perceived dysfunction within the backporters team, I feel it is > > > important to try and set some more specific expectations for how the > > > newly rebooted team would function - particularly to an outsider wishing > > > to contribute. > > The problem in my opinion is that also your (rbasak's) original proposal > is also "useless" for an aspiring contributor. Also, what's > "contributor" here? Somebody wanting to propose a backport update is > really not served by these documents (either Charter or Policies)... I wonder if it's worth first discussing what the text would actually be used *for*, since your reply suggests to me that we might not have the same view on this here. I see the (my) proposed text as a point of reference between the backporters team and the rest of the project, but generally only for use to guide the backporters team in defining their own policies, procedures and documentation, cases where it was unclear what their responsibilities are, or in case of some kind of unhappiness (eg. we hope it won't happen, but a repeat of the previous team being unable to review submissions at all). What I *don't* expect it to be used for directly is for anything to do with aspiring contributors. I would expect that to be covered by documentation that the backporters team controls and defines as they feel appropriate. Similarly you'd be free to adjust that documentation as the need arises, rather than having a "locked in" document that requires negotiation with a board to have changed. I think aspiring contributors would still benefit from having things clearly defined in this text, because that clarity would then filter down into your own processes, procedures and documentation. But I wouldn't expect them to actually _use_ the formal text directly (unless they were asking for changes in those processes, or wanted to escalate something). Robie signature.asc Description: PGP signature -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
Re: New proposal for Ubuntu Backporters Team Charter
On Wed, Mar 01, 2023 at 11:03:02AM +1030, Alex Murray wrote: > Just wondering if you had a chance to review my feedback? It would be > great to try and make some progress here. We have a meeting later today, but I'll give you my own inputs. The tl;dr: I'm more in-line with Dan comments. > >>> * Establish and manage an effective process to handle backport > >>>requests based solely on their technical merit. > >> > >> I'm not sure this is correct, to handle requests *solely* on technical > >> merit. For example, part of the backport process is the expectation > >> that the backport requestor/uploader will remain responsible for > >> further backports as needed; if an uploaded backport seems technically > >> correct but the backports team does not believe the uploader would be > >> responsible for further uploads, the backports team should be able to > >> reject the upload on that basis. > >> > >> Stating "solely on their technical merit" places undue restrictions on > >> our team, I believe. > >> > > > > I feel it is perhaps a bit too onerous to expect that just because a > > user contributes one backport that they then should be expected to keep > > doing backports for that package - this is placing undue restrictions on > > your possible contributors. Regardless though, I don't think the > > backports team should be trying to guess whether someone is likely to > > contribute further backports in the future - this leaves too much chance > > for the team to ignore proposed backports on arbitrary grounds. As such, > > this is the exact point of the statement "solely on their technical > > merit" - to give confidence to prospective users who want to contribute > > backports that their submissions will be treated in a fair manner. I'm sorry, but I do have and want to have some expectations that nobody does *1* drive-by contribution and upload, and then the package is left to bitrot in the backports pocket forevermore. Really, if that was their goal, they are better served by a PPA. We are clearly not enforcing this at this time, but I don't want to restrict us. From my own side, I'd propose this sentence instead: * Establish and manage an effective process and a set of policies to handle contributions to the "backports" pocket. > >>> * Maintain the backports pocket based on this process, with an aim to > >>>ensure all requests are responded to in a reasonable amount of time. > >> > >> What does "reasonable amount of time" mean? > >> > > > > This is purposely non-specific - but again is here to give prospective > > users confidence that their submissions will not sit ignored for an > > indefinite period. Too little specificity is not good. I'm not sure what's best (to write down an arbitrary timeframe or what else), but having this sentence so meaningless is worse than not having it, for me. Potentially, I'd be more open to have a SLA-like rule in our internal policies. > >>> * Maintain quality in the backports pocket, where the definition of > >>>quality is driven by the team, but decided by consensus within the > >>>wider Ubuntu developer community. > >> > >> I'm not quite sure what this statement is trying to achieve, or what > >> it would mean in practice. Can you clarify? > >> > > > > This allows the backports team to take the lead on defining what is > > required in terms of quality for submissions but also allows the > > community to give feedback / input as well. I'd drop this. Or at worse add a couple of words in the first point about us defining policies. > >>> * Handle process reform and membership management internally, ensuring > >>>that any responsibility can be carried by any contributor who > >>>demonstrates the required capacity and competence. > >> > >> I think this statement is even harder to read, can you clarify and/or > >> reword it? > >> > >> For example, if we must handle process/membership "internally", does > >> that mean we can't get outside input on those subjects? If not, then > >> what is the point of the statement at all? > >> > > > > This delegates authority to the backports team for these functions but > > again makes a statement that hopefully gives prospective contributors > > confidence that they can contribute just by demonstrating their > > abilities. I don't see why this statement as written would preclude > > getting outside input. Proposal: * Define a set of rules to handle the Backports Team memberships, its internal structure and members' responsabilities. > > So I think we are starting to get to the crux of the difference in > > viewpoints from the TB to the backporters team. Due to the past history > > of some perceived dysfunction within the backporters team, I feel it is > > important to try and set some more specific expectations for how the > > newly rebooted team would function - particularly to an outsider wishing > > to contribute. The problem in my opinion is that also your (rbasak's) original
Re: New proposal for Ubuntu Backporters Team Charter
Hi Backporters team, Just wondering if you had a chance to review my feedback? It would be great to try and make some progress here. Thanks, Alex On Fri, 2023-02-10 at 11:17:46 +1030, Alex Murray wrote: > On Wed, 2023-01-25 at 09:47:37 -0500, Dan Streetman wrote: > >> On Wed, Jan 25, 2023 at 12:21 AM Alex Murray >> wrote: >>> >>> Hi Ubuntu Backporters Team, >>> >>> The Tech Board is hoping to progress the ratification of a charter for >>> the Ubuntu Backporters Team as discussed previously on a number of >>> occasions. My understanding is that these previous discussions between >>> the Backporters Team and the Tech Board have not been able to reach a >>> consensus on both the level of detail and the requirements that would be >>> stipulated in the Charter. >>> >>> The previous drafts at https://wiki.ubuntu.com/UbuntuBackports/Charter >>> seemed to contain a mix of both high level statements/directions for the >>> team as well as lower-level policies for the operation of the team. I >>> notice that now most of these lower-level details have moved into >>> https://wiki.ubuntu.com/UbuntuBackports/Policies but there is still no >>> higher level Charter outlining the purpose and guiding principles for >>> the team. >>> >>> As such I propose the following as a starting point, which is based on >>> the previous proposal from rbasak[1] but which tries to reduce any >>> potential burdens placed on the team by such an overall Charter: >>> >>> >>> * Establish and manage an effective process to handle backport >>>requests based solely on their technical merit. >> >> I'm not sure this is correct, to handle requests *solely* on technical >> merit. For example, part of the backport process is the expectation >> that the backport requestor/uploader will remain responsible for >> further backports as needed; if an uploaded backport seems technically >> correct but the backports team does not believe the uploader would be >> responsible for further uploads, the backports team should be able to >> reject the upload on that basis. >> >> Stating "solely on their technical merit" places undue restrictions on >> our team, I believe. >> > > I feel it is perhaps a bit too onerous to expect that just because a > user contributes one backport that they then should be expected to keep > doing backports for that package - this is placing undue restrictions on > your possible contributors. Regardless though, I don't think the > backports team should be trying to guess whether someone is likely to > contribute further backports in the future - this leaves too much chance > for the team to ignore proposed backports on arbitrary grounds. As such, > this is the exact point of the statement "solely on their technical > merit" - to give confidence to prospective users who want to contribute > backports that their submissions will be treated in a fair manner. > >>> >>> * Maintain the backports pocket based on this process, with an aim to >>>ensure all requests are responded to in a reasonable amount of time. >> >> What does "reasonable amount of time" mean? >> > > This is purposely non-specific - but again is here to give prospective > users confidence that their submissions will not sit ignored for an > indefinite period. > >>> >>> * Maintain quality in the backports pocket, where the definition of >>>quality is driven by the team, but decided by consensus within the >>>wider Ubuntu developer community. >> >> I'm not quite sure what this statement is trying to achieve, or what >> it would mean in practice. Can you clarify? >> > > This allows the backports team to take the lead on defining what is > required in terms of quality for submissions but also allows the > community to give feedback / input as well. > >>> >>> * Handle process reform and membership management internally, ensuring >>>that any responsibility can be carried by any contributor who >>>demonstrates the required capacity and competence. >> >> I think this statement is even harder to read, can you clarify and/or reword >> it? >> >> For example, if we must handle process/membership "internally", does >> that mean we can't get outside input on those subjects? If not, then >> what is the point of the statement at all? >> > > This delegates authority to the backports team for these functions but > again makes a statement that hopefully gives prospective contributors > confidence that they can contribute just by demonstrating their > abilities. I don't see why this statement as written would preclude > getting outside input. > >>> >>> >>> I hope this can serve as a basis to reach a consensus that is amendable >>> to both the Backporters Team and Technical Board. >> >> As a counter proposal, what do you think of this simple "charter": >> >> * Maintain the Ubuntu "backports" pocket. >> > > Whilst this is nice and simple, I feel it leaves far too much open to > interpretation. > > So I think we are starting to get to the crux of the difference in >
Re: New proposal for Ubuntu Backporters Team Charter
On Wed, 2023-01-25 at 09:47:37 -0500, Dan Streetman wrote: > On Wed, Jan 25, 2023 at 12:21 AM Alex Murray > wrote: >> >> Hi Ubuntu Backporters Team, >> >> The Tech Board is hoping to progress the ratification of a charter for >> the Ubuntu Backporters Team as discussed previously on a number of >> occasions. My understanding is that these previous discussions between >> the Backporters Team and the Tech Board have not been able to reach a >> consensus on both the level of detail and the requirements that would be >> stipulated in the Charter. >> >> The previous drafts at https://wiki.ubuntu.com/UbuntuBackports/Charter >> seemed to contain a mix of both high level statements/directions for the >> team as well as lower-level policies for the operation of the team. I >> notice that now most of these lower-level details have moved into >> https://wiki.ubuntu.com/UbuntuBackports/Policies but there is still no >> higher level Charter outlining the purpose and guiding principles for >> the team. >> >> As such I propose the following as a starting point, which is based on >> the previous proposal from rbasak[1] but which tries to reduce any >> potential burdens placed on the team by such an overall Charter: >> >> >> * Establish and manage an effective process to handle backport >>requests based solely on their technical merit. > > I'm not sure this is correct, to handle requests *solely* on technical > merit. For example, part of the backport process is the expectation > that the backport requestor/uploader will remain responsible for > further backports as needed; if an uploaded backport seems technically > correct but the backports team does not believe the uploader would be > responsible for further uploads, the backports team should be able to > reject the upload on that basis. > > Stating "solely on their technical merit" places undue restrictions on > our team, I believe. > I feel it is perhaps a bit too onerous to expect that just because a user contributes one backport that they then should be expected to keep doing backports for that package - this is placing undue restrictions on your possible contributors. Regardless though, I don't think the backports team should be trying to guess whether someone is likely to contribute further backports in the future - this leaves too much chance for the team to ignore proposed backports on arbitrary grounds. As such, this is the exact point of the statement "solely on their technical merit" - to give confidence to prospective users who want to contribute backports that their submissions will be treated in a fair manner. >> >> * Maintain the backports pocket based on this process, with an aim to >>ensure all requests are responded to in a reasonable amount of time. > > What does "reasonable amount of time" mean? > This is purposely non-specific - but again is here to give prospective users confidence that their submissions will not sit ignored for an indefinite period. >> >> * Maintain quality in the backports pocket, where the definition of >>quality is driven by the team, but decided by consensus within the >>wider Ubuntu developer community. > > I'm not quite sure what this statement is trying to achieve, or what > it would mean in practice. Can you clarify? > This allows the backports team to take the lead on defining what is required in terms of quality for submissions but also allows the community to give feedback / input as well. >> >> * Handle process reform and membership management internally, ensuring >>that any responsibility can be carried by any contributor who >>demonstrates the required capacity and competence. > > I think this statement is even harder to read, can you clarify and/or reword > it? > > For example, if we must handle process/membership "internally", does > that mean we can't get outside input on those subjects? If not, then > what is the point of the statement at all? > This delegates authority to the backports team for these functions but again makes a statement that hopefully gives prospective contributors confidence that they can contribute just by demonstrating their abilities. I don't see why this statement as written would preclude getting outside input. >> >> >> I hope this can serve as a basis to reach a consensus that is amendable >> to both the Backporters Team and Technical Board. > > As a counter proposal, what do you think of this simple "charter": > > * Maintain the Ubuntu "backports" pocket. > Whilst this is nice and simple, I feel it leaves far too much open to interpretation. So I think we are starting to get to the crux of the difference in viewpoints from the TB to the backporters team. Due to the past history of some perceived dysfunction within the backporters team, I feel it is important to try and set some more specific expectations for how the newly rebooted team would function - particularly to an outsider wishing to contribute. This is not trying to constrain the
Re: New proposal for Ubuntu Backporters Team Charter
On Wed, Jan 25, 2023 at 12:21 AM Alex Murray wrote: > > Hi Ubuntu Backporters Team, > > The Tech Board is hoping to progress the ratification of a charter for > the Ubuntu Backporters Team as discussed previously on a number of > occasions. My understanding is that these previous discussions between > the Backporters Team and the Tech Board have not been able to reach a > consensus on both the level of detail and the requirements that would be > stipulated in the Charter. > > The previous drafts at https://wiki.ubuntu.com/UbuntuBackports/Charter > seemed to contain a mix of both high level statements/directions for the > team as well as lower-level policies for the operation of the team. I > notice that now most of these lower-level details have moved into > https://wiki.ubuntu.com/UbuntuBackports/Policies but there is still no > higher level Charter outlining the purpose and guiding principles for > the team. > > As such I propose the following as a starting point, which is based on > the previous proposal from rbasak[1] but which tries to reduce any > potential burdens placed on the team by such an overall Charter: > > > * Establish and manage an effective process to handle backport >requests based solely on their technical merit. I'm not sure this is correct, to handle requests *solely* on technical merit. For example, part of the backport process is the expectation that the backport requestor/uploader will remain responsible for further backports as needed; if an uploaded backport seems technically correct but the backports team does not believe the uploader would be responsible for further uploads, the backports team should be able to reject the upload on that basis. Stating "solely on their technical merit" places undue restrictions on our team, I believe. > > * Maintain the backports pocket based on this process, with an aim to >ensure all requests are responded to in a reasonable amount of time. What does "reasonable amount of time" mean? > > * Maintain quality in the backports pocket, where the definition of >quality is driven by the team, but decided by consensus within the >wider Ubuntu developer community. I'm not quite sure what this statement is trying to achieve, or what it would mean in practice. Can you clarify? > > * Handle process reform and membership management internally, ensuring >that any responsibility can be carried by any contributor who >demonstrates the required capacity and competence. I think this statement is even harder to read, can you clarify and/or reword it? For example, if we must handle process/membership "internally", does that mean we can't get outside input on those subjects? If not, then what is the point of the statement at all? > > > I hope this can serve as a basis to reach a consensus that is amendable > to both the Backporters Team and Technical Board. As a counter proposal, what do you think of this simple "charter": * Maintain the Ubuntu "backports" pocket. > > I welcome any feedback from all involved (please note I am not > subscribed to the ubuntu-backports list so please CC me directly on > responses). > > Thanks, > Alex > > > [1] > https://lists.ubuntu.com/archives/ubuntu-backports/2022-February/022687.html > > -- > ubuntu-backports mailing list > ubuntu-backports@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
New proposal for Ubuntu Backporters Team Charter
Hi Ubuntu Backporters Team, The Tech Board is hoping to progress the ratification of a charter for the Ubuntu Backporters Team as discussed previously on a number of occasions. My understanding is that these previous discussions between the Backporters Team and the Tech Board have not been able to reach a consensus on both the level of detail and the requirements that would be stipulated in the Charter. The previous drafts at https://wiki.ubuntu.com/UbuntuBackports/Charter seemed to contain a mix of both high level statements/directions for the team as well as lower-level policies for the operation of the team. I notice that now most of these lower-level details have moved into https://wiki.ubuntu.com/UbuntuBackports/Policies but there is still no higher level Charter outlining the purpose and guiding principles for the team. As such I propose the following as a starting point, which is based on the previous proposal from rbasak[1] but which tries to reduce any potential burdens placed on the team by such an overall Charter: * Establish and manage an effective process to handle backport requests based solely on their technical merit. * Maintain the backports pocket based on this process, with an aim to ensure all requests are responded to in a reasonable amount of time. * Maintain quality in the backports pocket, where the definition of quality is driven by the team, but decided by consensus within the wider Ubuntu developer community. * Handle process reform and membership management internally, ensuring that any responsibility can be carried by any contributor who demonstrates the required capacity and competence. I hope this can serve as a basis to reach a consensus that is amendable to both the Backporters Team and Technical Board. I welcome any feedback from all involved (please note I am not subscribed to the ubuntu-backports list so please CC me directly on responses). Thanks, Alex [1] https://lists.ubuntu.com/archives/ubuntu-backports/2022-February/022687.html -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
