On 04/06/19 20:24, Max Rees wrote:
On Apr 01 11:54 PM, A. Wilcox wrote:
> Our first act in this charter is to define "Projects". A Project
> is a collective of contributors working towards a common goal.
> This goal should be on-going and clearly defined (see Interest
> Groups below for one-time tasks). At least one Committer is
> required to form a Project.
For projects which are completely orthogonal to packaging, is there
another requirement that could be used instead? For example,
documentation projects need write access to other git repositories,
but not necessarily packages.git.
A Committer is someone who has write access to at least one repository.
(That could even be Shimmy or gcompat.)
> The Project proposal must contain the name of the project, the
> desired short name for the mailing list, and the common goal it
> wishes to achieve.
It may be useful to add a requirement here to list the project's
initial members.
I was a bit leery of this because I didn't want people to be maliciously
added. Consider mailing lists; they require a confirmation email before
being subscribed.
I was going to add something like: "It may additionally include a list
of initial contributors, which will be contacted to ensure their desired
participation." But that adds more work for the Platform Group. Of
course, if we're letting the project define their members, maybe that
could happen anyway... unless we take subscription to the project's ML
as an implicit desire to join.
This should probably be discussed further, either here or IRC.
> Disbanding a Project
> --------------------
>
> A Project may be disbanded without Platform Group interference if
> all Committers assigned to the Project wish it so.
>
> The Platform Group may disband a project with a three-fourths
> majority.
>
> When a Project is disbanded, its mailing list must be made
> read-only, but its archives must not be destroyed. The Platform
> Group may decide whether to archive or destroy the Project's Web
> space. In the event of destruction, URLs must be set to return a
> '410 Gone' response.
What happens in the event of the Platform Group disbanding?
Additionally, project web spaces should probably be preserved unless
it causes an undue burden on storage resources.
Maybe it should be made explicit that the Platform Group cannot be
disbanded since that would be the end of Adélie (and should probably be
done more formally than disbanding the Platform Group).
The Platform Group decides whether to archive or destroy the Web space.
I can't imagine a case where we would want to destroy it unless it was
not in line with our code of conduct.
> Interest Groups will be granted Web space for any documentation
> they feel appropriate. Interest Groups, like Projects, shall
> maintain a list of Committers on this Web space. They may,
> additionally, list non-Committer regular contributors, though this
> is not required.
How is an interest group formed? Is there a formal process for this?
Perhaps similar to that for projects, or maybe they can be formed ad
hoc.
This was never agreed upon. Suggestions are welcome; I'd prefer it to
be more ad-hoc than the formal Project requests.
> The Platform Group handles addition and removal of Committers.
By what process are committers inducted? I believe this is
documented elsewhere, but it may be beneficial to include here.
An explicit link to that should be included, but I don't think the
organisational structure is an appropriate place to put that. Mostly
because we may want to amend those processes while we continue to grow,
and I don't think we should be amending this charter often.
> If the Platform Group does not approve the expulsion, it may be
> overridden by a complete approval of the expulsion by every
> Committer.
I understand the high bar set here for overriding a failed platform
group member expulsion, but obtaining the approval of every single
committer seems a little impractical. I'm not sure what to suggest
however. In this event ComArb should probably be involved as well,
unless they initiated the proposal? As discussed on IRC it would
probably also help to clarify that members of ComArb cannot also be
members of the Platform Group.
90%? Anything short of "every Committer" is going to be arbitrary.
Added the note about ComArb =/= PG.
> In the event of a Platform Group vote resulting in a tie, the
vote
> of the current Project Lead will be carried. If the Project Lead
> is absent, the vote of the senior-most present member of the
> Platform Group will be carried.
There is currently no definition of "Project Lead" in this document.
Less importantly there is no definition of "senior-most" nor
"present" member.
Overall however I agree with this proposal in the general sense, it
just needs clarification on the above points.
Max
I'm very unsure of how to define "Project Lead". I've added a
definition of seniority and clarified presence.
The new version of the charter will be sent to the list after these
issues and the other issues raised in this thread have been handled.
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org