New proposal for Ubuntu Backporters Team Charter

Tue May 30 19:15:35 UTC 2023

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 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 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)...
>>>
>>>> > This is not trying to constrain the efforts of those on
>>>> > the team in any way, but more trying to set an expectation of quality
>>>> > for all possible contributions, and to also give contributors confidence
>>>> > that their submissions won't potentially be in vain. Overall, this is
>>>> > really about trying to ensure the backports subcommunity is vibrant and
>>>> > welcoming to encourage contributions, and not potentially perceived as a
>>>> > gated group that is only accessible to the special few.
>>>
>>> I don't think I look forward to any sort of "backports subcommunity", so
>>> I'm afraid we might have some sort of disconnect here.
>>>
>>> What I look forward is more people interested in backporting updates to
>>> the packages they are (and keep being) interested in.  I don't imagine
>>> these people forming any kind of submcommunity around backports, rather
>>> those being mostly regular ubuntu develpers that have an extra interest.
>>> Are we trying to assure these people?  I joined this team reboot because
>>> in the past the team just died, nobody knew who was responsibile for
>>> what, etc.  In my view, the best reassurance we can give to those
>>> potential contributors, is being actually available to their enquiries
>>> and requests.
>>>
>>>
>>> Summing up my proposal:
>>>
>>>   * 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' responsabilities.
>>>
>>> -- 
>>> 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-board at lists.ubuntu.com
>>> https://lists.ubuntu.com/mailman/listinfo/technical-board
>>
>> -- 
>> technical-board mailing list
>> technical-board at lists.ubuntu.com
>> https://lists.ubuntu.com/mailman/listinfo/technical-board
>
> -- 
> technical-board mailing list
> technical-board at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/technical-board