[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Amendment to the Constitution: Add a new foundation document



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I think this draft is very good, and I am most pleased to second it.

So I second this proposed foundation document.  

Excellent work, Manoj!

Thomas


Manoj Srivastava <srivasta@debian.org> writes:

> Here is the current version
> 
> 	manoj.
> 
>  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.
> 
>  $(B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,
(B> 
>   1. A Foundation Document is a document or statement regarded as
>      critical to the Project's mission and purposes.
> 
>   2. The Foundation Documents are the works entitled `Debian
> -       Social Contract' and `Debian Free Software Guidelines'.
> +       Social Contract', `Transition Guide' and
> +      `Debian Free Software Guidelines'.
> 
>   3. 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.
> 
>  $(B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,
(B> 
>  The attached Transition guide is:
> 
>                            Transition Guide
> 
>  A working guide to achieve the transition for changes in Foundation documents
> 	 containing explanations and Rationale, and defining
> 		  guidelines for future transitions
> 
> 
>  The Social Contract represents the core commitments of the Project.
>  The Social Contract leaves its marks in many ways; it is deeply
>  intertwined with all parts of the Project. Potentially, 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. Whenever we change these commitments, we may 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, a minor version
>  was released 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 one developer has
>  said:
> 
>      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.
> 
>  We, the Debian Project, do so affirm this judgmen. 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.
> 
>  Whenever a change to our foundation documents 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), and 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.
> 
>  Since this modifies the Constitution, this requires a 3:1 majority to
>  pass.
> 
> 
> -- 
> Tell the truth or trump--but get the trick. Mark Twain, "Pudd'nhead
> Wilson's Calendar"
> Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
> 1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
> 1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFAlfQzqMsB9b6fcOoRAkz+AKCXpJnROXR2VlCp+C6nmPDkuxgoxgCcCrrl
a5bIaQVofo/VD+Jpm0xnSa0=
=VwgC
-----END PGP SIGNATURE-----



Reply to: