Hi,
I'd like to follow up on this with an update and hopefully get things
moving. See below for a continuation of the discussion regarding ACL
setup for the new repo.
On Tue, Sep 2 25 12:16, Robert Kratky wrote:
[snip]
>>> This setup is what I'd like to offer the Board and SRU. I believe the
>>> case for consolidating all this content in one place is sound, and the
>>> CODEOWNERS setup ensures the content wouldn't be out of your team's
>>> control.
>>>
>>> The one potentially sticky point is that it's on GitHub, i.e. the
>>> involved people would need a GH account for the ACL to work. We can
>>> include people individually, which is what we've been doing so far.
>>> Special GitHub teams could also be set up for that purpose.
>>>
>>> (We've also been looking into auto-syncing LP -> GH teams, so this
>>> access control would continue to be automatically based on LP team
>>> membership...
>>
>> I think it's important that friction to make changes remains low. We
>> must avoid creating "second class citizen" governance team members
>> because team membership changes haven't propogated. Please could you
>> ensure that whatever process you use, changes propagate without
>> intervention and without delay?
>
> If set up using the mechanism that IS has in place for syncing LP and
> GH teams, this would be automatic.
>
>> You'll presumably need a mapping from Launchpad accounts to GitHub
>> accounts. Maybe the Launchpad "social accounts" feature could be used
>> for this, like for Matrix. But then you'll need to ensure to propagate
>> both on Launchpad team membership changes as well as mapping changes,
>> and perhaps this needs some thought about validation.
>
> I'm talking to IS to see what we can come up with regarding the mapping.
> In the meantime, I'd suggest we go the route of indiv. accounts in the
> CODEOWNERS file. I realize that's a sub-optimal long-term solution, but
> I think it's a good stop-gap while the larger docs set is WIP.
Following further discussion with the IS team, it's clear they cannot
dedicate cycles to adapting their LP -> GH sync solution for our
purposes right now.
Therefore, I'd like to move forward with the previously suggested
(temporary) alternative: using individual GitHub account IDs in the
CODEOWNERS file. I realize this is a sub-optimal solution as it requires
a manual intervention to reflect any potential changes to team
composition.
However, in view of the fact that the 'Ubuntu Project' docs are now
being actively worked on (and this focus is planned to continue during
the 26.04 cycle), I'm convinced there'd be no danger of creating "second
class citizens" as Robie put it.
Meanwhile, we'd be working on automating the process as discussed above
-- either using the IS solution (provided the team can accommodate
us), or otherwise.
If there's no opposition to this plan, I'd like to go ahead with it next
week.
Robert
