Procedures for submitting a General Resolution proposal or amendment
Under the following sections of the constitution
The following procedures have been instituted regarding general resolution proposals and sponsoring.
- The electronic mailing list designated is email@example.com. This is the authoritative source of the full text of all resolutions, as well as the supporting arguments and other material. Proposals, or sponsorship motions shall not be recognized if sent to any other mailing list.
- Every proposal and sponsoring email must be signed with the cryptographic key that lives in the Debian keyrings. The keyrings are part of the authoritative answer to who is or is not a Debian developer.
- Every proposal must clearly indicate the bounds of the proposal, which must be clearly delineated from surrounding text of the mail message. Every sponsor must also indicate the text they are sponsoring, if only to indicate that they recognize the bounds set by the proposer.
- When the vote is called, the proposer or a sponsor of every proposal or amendment must provide a final version of the proposal or amendment in wml format for inclusion on the web pages of the Debian project. This wml snippet must be verified to contain exactly the text that was delineated and sponsored.
- When the vote is called, the proposer or a sponsor of every proposal or amendment must provide a single line (60 character) synopsis of their proposal or amendment. This synopsis shall be taken into account by the secretary when creating the ballot.
Failing items 4 and 5, the secretary's version shall be deemed final. It is strongly suggested that the proposers and sponsors be prepared with the matter in question before the end of the minimal discussion period, since the vote shall not be delayed on account of these missing items.
Recommended practices and style
The following is informative as opposed to normative. These suggestions would make the it easier to understand, follow, and vote upon the proposal. A sample template has been provided as a starting point.
It is good practice to include a concise description of the
proposal in the subject line of the email. It is recommended
that the subject line be formatted like
Subject: Proposal - descriptive text, this helps
people in filtering mails related to the proposal.
Indicate whether your proposal is an independent proposal, or is a formal amendment to an existing proposal. You may create an independent proposal addressing the same issue an existing proposal does; the difference is mostly one of timing. An amendment may not get the full discussion period; and the vote may be called before you are done refining your amendment. An independent proposal, on the other hand, may not get to be on the same ballot as the existing proposal, depending on timing, and there could be two independent votes, one for the existing proposal, and one for your new independent proposal. The final decision lies with you.
If your proposal is a change to the text of an existing
document, providing an actual patch file (as generated by
diff -u) is a good idea, since it clearly shows
exactly what changes are being proposed, and helps the person in
charge of the document if your proposal passes.
One suggestion to proposers and sponsors is that the full text of the proposal or amendment be put into a separate (perhaps in-lined) signed text/plain MIME part, so there is absolutely no ambiguity.