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.
> 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.
> 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.
> 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.
> 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.
> 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.
> 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
Received on Sun Apr 07 2019 - 01:27:25 UTC