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