New proposal for Ubuntu Backporters Team Charter

Alex Murray alex.murray at canonical.com
Wed Mar 1 00:33:02 UTC 2023


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 <alex.murray at canonical.com> 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 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 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 at lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
>
> -- 
> technical-board mailing list
> technical-board at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/technical-board



More information about the technical-board mailing list