Re: Amendment to the Constitution: Add a new foundation document
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Manoj Srivastava <srivasta@debian.org> writes:
> Hi,
>
> On consultation with the other sponsors, I have decided to
> add a sunset clause to the proposed "Transition Guide", so that the
> specific references to Sarge are ex-purged after it is released.
>
> This new version has been proof read by David Harris, and is
> in much better shape than my initial offering. On their request, I
> have removed the names for Raul MIller and Joey Hess, though I thank
> them for helping me form my view, in the now unattributed emails.
>
> To recap, in order to handle the changes introduced in the GR
> 2004_003:
> ----------------------------------------------------------------------
> I propose we adopt a foundation document that tries to provide
> guidance and explanation for the transitions required whenever a
> change occurs in a foundation document like the social contract, and
> also provides specific remedies to the current dilemma that we find
> ourself in. This GR proposal is related to the GR currently in
> discussion for deferring of the changes made in GR 2004_003, and
> would be on the same ballot, and is an alternative to the GR
> currently in discussion.
>
> I hereby propose that we amend the constitution to add to the
> list of foundation documents the document attached in this proposal,
> titled "Transition Guide". The context diff follows.
> ----------------------------------------------------------------------
> <OL style="list-style: decimal;">
> <LI>A Foundation Document is a document or statement regarded as
> critical to the Project's mission and purposes.</LI>
> <LI>The Foundation Documents are the works entitled <q>Debian
> - Social Contract</q> and <q>Debian Free Software Guidelines</q>.</LI>
> + Social Contract</q>, <q>Transition Guide</q> and
> + <q>Debian Free Software Guidelines</q>.</LI>
> <LI>A Foundation Document requires a 3:1 majority for its
> supersession. New Foundation Documents are issued and
> existing ones withdrawn by amending the list of Foundation
> Documents in this constitution.</LI>
> </OL>
> ----------------------------------------------------------------------
>
> It is further resolved that the final paragraph of the "Transition
> Guide" with specific references to the forthcoming release (code named
> "Sarge") shall be removed from the "Transition Guide" upon the next
> full release of Debian after Debian 3.1 (code named "Sarge"), without
> further cause for deliberation.
>
> It is resolved that the full text of the proposed foundation document
> be the following:
>
>
> Transition Guide
>
> A working guide to achieve the transition for changes in Foundation
> documents with specific remedies for the change in the social contract
> made by GR 2004_003 containing explanations and Rationale, and defining
> guidelines for future transitions
>
> In General Resolution 2004_003, the wording of the Social Contract was
> modified. The Social Contract represents the core commitments of the
> Project. The Social Contract leaves its marks in many ways, it's deeply
> intertwined with the all parts of the Project. Any change to the Social
> Contract has major ramifications, and may require a period of
> potentially deep changes to the roots of the Project before it can come
> into compliance with the changed Contract.
>
> Meeting our commitments as described in the Social Contact is an ongoing
> process. Since we have recently changed these commitments, we need an
> interval of time before we can approach compliance. Unless we shut down
> the Project completely - abandoning users and our developers - the
> regular activities of the Project must continue while we work towards
> compliance.
>
> There is precedent for a gap between ratifying a change to the
> foundation documents of the Project and implementing dictates of that
> document; when the Project first accepted the Social Contract and the
> Debian Free Software Guidelines, there was an interval before we came
> into compliance with those then-new documents. Indeed, there was the
> release of a minor version just days after the Debian Free Software
> Guidelines were accepted, and this release by no means complied with the
> new commitments.
>
> We also continued to support older non-complying releases, and did not
> make them unavailable to our users.
>
> The binding principle here is that we have to balance the needs of our
> users and the need to make Debian strictly free. As seen on the mailing lists:
>
>
> In my opinion, the needs of the free software community take
> precedence in the context of adopting new packages, in the setting
> of release goals, in our choices about infrastructure and
> philosophy, and of course in the context of any development work we
> do.
>
> In my opinion, the needs of our users take precedence in the context
> of security fixes, in the context of support for packages and
> systems we've released, and in the context of the quality of our
> work.
>
>
> With this document, we, the Debian Project, do so affirm this. We affirm
> that while we are working towards complying with a change in the goals
> or identity of the Project, or towards compliance with any change to a
> foundation document, the needs of our users will be catered to. This may
> mean that for a limited time, Debian will not be compliant with the new
> Social Contract.
>
> We affirm that whenever a change to the Social Contract, or the
> Constitution, takes place, the activities required to provide ongoing
> and proactive support for the Debian user community shall
> continue. This includes, but is not necessarily limited to, providing
> security updates for previously-released versions of Debian, providing
> point-release updates to previously-released versions of Debian,
> preparing for the next (compliant) release of Debian, actually
> releasing the current non-compliant version of Debian if such a
> release is imminent (as well as any further updates to that version of
> Debian), as well as providing all the Project's infrastructure such as
> bug-tracking and mailing lists.
>
> In the specific case of General Resolution 2004_003, since that release
> currently in preparation, code named "Sarge", is very close to release,
> and the previously released version is quite out of date, our commitment
> to our users dictates that the "Sarge" release should go on as planned -
> even while we are in the process of reaching compliance with the new
> Social Contract. This exemption for "Sarge" applies to security releases
> and point releases as well.
>
>
>
> Rationale
>
> My intent was not just to find a way for us to allow to release Sarge,
> it was to create a guideline to help ease us through major changes in
> something like the Social contract, or the constitution. The fact that
> a generic transition guide may help us also release Sarge soon is a
> nice side effect.
>
> It has been suggested that transitioning ought to be handled in the
> original proposal itself, and yes, that is a good idea. But foresight
> is weak, compared to 8/20 hind sight, and there may be unforeseen
> consequences of a proposed change that were not evident while drafting
> the proposal.
>
> Nothing is perfect. I would much rather we also had a process defined
> to pick up the pieces if the before-the-fact transition plan blew up
> in our face; this is way better than relying on perfect foresight in
> transition plans.
>
> The other issue addressed in the proposal is one of choosing between
> two different requirements of the social contract; and how to balance
> these different requirements when some of these requirements are
> changed.
> ======================================================================
>
> I would appreciate it if the people who seconded the original
> proposal also second the modifications made in adding the sunset
> clause, and the typographical changes wrought.
>
I second it.
- --
Rémi Vanicat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFAlYnesOGY15BXtdMRAg3jAJ4m8HlMVvF4WwPEtPhpdhJAHMF3MACgg0mM
9kvU1e4vD6pK0w3WUP9ZAVA=
=/1jP
-----END PGP SIGNATURE-----
Reply to: