1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
|
<define-tag pagetitle>Procedures for submitting a General Resolution proposal or amendment</define-tag>
#use wml::debian::template title="<pagetitle>" BARETITLE="true" NOHEADER="true" NOHOMELINK="true"
#use wml::debian::votebar
<h1><pagetitle></h1>
<p>Under the following sections of the constitution</p>
<div style="border: solid; padding: 1ex">
<blockquote>
<ul>
<li>
4. The Developers by way of General Resolution or election
<ul>
<li>
2. Procedure
<ul>
<li>
5. Proposals, sponsors, amendments, calls for votes and
other formal actions are made by announcement on a
publicly-readable electronic mailing list designated by
the Project Leader's Delegate(s); any Developer may post
there.
</li>
<li>
6. Votes are cast by email in a manner suitable to the
Secretary. The Secretary determines for each poll
whether voters can change their votes.
</li>
</ul>
</li>
</ul>
</li>
</ul>
<ul>
<li>
A. Standard Resolution Procedure
<ul>
<li>
3. Voting procedure
<ul>
<li>
4. In cases of doubt the Project Secretary shall decide on
matters of procedure.
</li>
</ul>
</li>
</ul>
</li>
</ul>
</blockquote>
</div>
<p>
The following procedures have been instituted regarding general
resolution proposals and sponsoring.
</p>
<ol style="list-style-type: decimal">
<li>
The electronic mailing list designated is
<tt>debian-vote@lists.debian.org</tt>. 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.
</li>
<li>
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.
</li>
<li>
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.
</li>
<li>
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.
</li>
<li>
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.
</li>
</ol>
<p>
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.
</p>
<h1>Recommended practices and style</h1>
<p>
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 <a
href="sample_vote.template">template</a> has been provided as a
starting point.
</p>
<p>
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
<q><em>Subject: Proposal - descriptive text</em></q>, this helps
people in filtering mails related to the proposal.
</p>
<p>
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.
</p>
<p>
If your proposal is a change to the text of an existing
document, providing an actual patch file (as generated by
<code>diff -u</code>) 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.
</p>
<p>
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.
</p>
<h2><a name="amend">Amending</a></h2>
<div style="border: solid; padding: 1ex">
<blockquote>
<ul>
<li>
A. Standard Resolution Procedure
<ul>
<li>
1. Discussion and Amendment
<ul>
<li>
5. The proposer of a resolution may suggest changes
to the wordings of amendments; these take effect
if the proposer of the amendment agrees and none
of the sponsors object. In this case the changed
amendments will be voted on instead of the
originals.
</li>
<li>
6. The proposer of a resolution may make changes to
correct minor errors (for example, typographical
errors or inconsistencies) or changes which do not
alter the meaning, providing no one objects within
24 hours. In this case the minimum discussion
period is not restarted.
</li>
</ul>
</li>
</ul>
</li>
</ul>
</blockquote>
</div>
|
