New proposal for Ubuntu Backporters Team Charter

Wed Mar 1 15:22:13 UTC 2023

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  `-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20230301/2e5bf6a5/attachment.sig>