Ubuntu Backports charter

[Robie Basak]

On Tue, Mar 22, 2022 at 04:46:45PM -0400, Dan Streetman wrote:
> > However the equivalent text you have now only says "The mission of the
> > Ubuntu Backporters Team is to maintain the backports pocket of all
> > stable Ubuntu releases." with no mention of that.
> >
> > In fact that's the case for basically everything I proposed previously.
> >
> > Is this deliberate? Would you consider replacing your "Mission
> > Statement" with the text I suggested previously?
> 
> I don't think so, no.
> 
> > And if not, why not?
> 
> Because your statements aren't a mission, they are policy; and your
> statements are not objective. For example, "all requests receive an
> appropriate answer in a reasonable amount of time" is not at all
> objective and so has no actual meaning in a charter.

I'm not sure if we're arguing semantics here in terms of what we each
mean by "mission", "policy" and "charter". I'd like to avoid that.

I am suggesting that we (both the TB and the backporters team) agree to
these statements because they would be able to form the documented terms
of reference between the rest of Ubuntu and backporters team. They would
be the reason for the existence of the backporters team. If a future
problem were to arise like the one we had in the past that led to the
recent revitalization, then we would be able to use these statements to
quickly identify the problem.

I agree that "reasonable amount of time" is subjective. However I don't
think it's a problem for there to be subjectivity here. Objectively, it
was the fact that requests _weren't_ being processed in a reasonable
amount of time that was the problem last time. Stating and agreeing to
this helps set expectations.

Consider what would happen if the backporters team stopped responding to
requests, or became unreasonably slow in doing so. That would obviously
be a problem - just as it was previously. If it couldn't be resolved
directly between everyone involved, somebody might escalate to the TB,
and the TB would probably agree that some intervention is required. In
other words, it's *already* a hard expectation that "all requests
receive an appropriate answer in a reasonable amount of time" whether or
not it's written down and directly agreed to. So why don't we agree and
write it down to help set everyone's expectation to what the reality is
anyway? Isn't that the point of documenting this kind of thing, and
exactly the sort of documentation you've said elsewhere you think is
lacking?

> > > > IMHO it's best if each team - including the backporters team - decides
> > > > for themselves how they want to operate, and are free to change things
> > > > as and when they want. To that extent, if the backporters team wants
> > > > have a detailed document like the one you have written, then that's
> > > > absolutely fine.
> > > >
> > > > But why are you looking for the TB to "ratify" it
> > >
> > > So that the powers delegated to the team are explicitly stated...
> >
> > I agree that this part makes sense.
> >
> > > that the "main" rules are also explicitly stated (with "main" being
> > > subjective, and decided by our team).
> >
> > Why do you want this to be part of the TB's ratification?
> 
> Because it's completely unclear what powers/policies/rules the TB
> reserves for itself.

Am I right in understanding that your concern is that the TB will later
tell you that you aren't allowed to do something that you've written
down in your rules already?

Would it work for you if the TB were to look at your document and agree
just that the set of rules you've written for yourself seem reasonable
and are all within the remit of the backporters team to perform, rather
than also formally binding anyone to anything?

I would still like to talk about having a documented delegation in the
form that I proposed, but this suggestion would address my separate
concern that you're asking the TB to lock the backporters team down in a
way that I don't think is appropriate.

> There is no section called "team responsibilities" nor "powers
> delegated to the team" so I'm not 100% clear on what you *do* think
> the TB needs to ratify, vs. what you *do not* think the TB should be
> involved in...can you clarify?

"powers delegated to the team" were your words. "team responsibilities"
are a heading in my email here:
https://lists.ubuntu.com/archives/ubuntu-devel/2021-July/041559.html

Specifically what I think would be useful for the TB to ratify is what I
wrote in my email here:

https://lists.ubuntu.com/archives/ubuntu-backports/2022-February/022687.html

> Any sections that you feel should be removed from the Charter (i.e.
> moved into the team official policies document:
> https://wiki.ubuntu.com/UbuntuBackports/Policies), please let me know.
> Assuming you are speaking for the TB, of course.

I think it's premature to "speak for the TB" at this stage. Let's first
try and figure out a way forward that everyone agrees upon. If we can
achieve that, then "speaking for" any particular team becomes
unnecessary; we can all just proceed on the basis of that agreement.

Robie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20220405/71f0c5ab/attachment.sig>