<p>
On Debian GNU/Linux systems, the complete text of the GNU
General Public License can be found in
<p>
On Debian GNU/Linux systems, the complete text of the GNU
General Public License can be found in
rather than authors/editors. This group does not create
policy, nor does it exercise editorial control, Policy is
decided "upstream". The group that decides on policy should
rather than authors/editors. This group does not create
policy, nor does it exercise editorial control, Policy is
decided "upstream". The group that decides on policy should
- be the group of developers on the Debian-policy mailing
- lists, which is how it was always done; so the group of
+ be the group of developers on the debian-policy mailing
+ list, which is how it was always done; so the group of
policy maintainers have no real power over policy.
</p>
<p>
Since the policy maintainers have no special powers, there
is no restriction of their participattion the discussion. It
policy maintainers have no real power over policy.
</p>
<p>
Since the policy maintainers have no special powers, there
is no restriction of their participattion the discussion. It
- is preferable to have atleast 4-5 people on the job,
- perhapscloser to 8, so that policy does not languish when
+ is preferable to have at least 4-5 people on the job,
+ perhaps closer to 8, so that policy does not languish when
any maintainer goes missing (we do need vacations, you know,
once in a while), and since little creative power is vested
in the maintainers, we do not need a central control. And
any maintainer goes missing (we do need vacations, you know,
once in a while), and since little creative power is vested
in the maintainers, we do not need a central control. And
There is a repository set up on <tt>cvs.debian.org</tt> for
this, and the people on the policy maintainer team have
write access to it. The Debian policy mailing list gets
There is a repository set up on <tt>cvs.debian.org</tt> for
this, and the people on the policy maintainer team have
write access to it. The Debian policy mailing list gets
<p>
Any Debian developer can create a proposal by retitling the
wishlist bug in the BTS to have the subject of the form
<p>
Any Debian developer can create a proposal by retitling the
wishlist bug in the BTS to have the subject of the form
around, and polished. There is no preset time limit, but at
some point, if it is stalled, the bug should be closed. A
suggested time period is 6 months, since if the
proposal has had no action in that period, it is very likely
dead. If six months have actually passed, the bug should be
retitled <strong>"[OLD PROPOSAL] ..."</strong>, and have the
around, and polished. There is no preset time limit, but at
some point, if it is stalled, the bug should be closed. A
suggested time period is 6 months, since if the
proposal has had no action in that period, it is very likely
dead. If six months have actually passed, the bug should be
retitled <strong>"[OLD PROPOSAL] ..."</strong>, and have the
- severity set to fixed. The maintianers shall flush out old
- proposal after a a suuficiently long period of time
- (cetainly more than a year or so).
+ severity set to fixed. The maintainers shall flush out old
+ proposals after a a sufficiently long period of time has
+ elapsed (certainly more than a year or so after the initial
+ proposal).
- developers may second the issue by emailing "seconded"
- to the BTS. Only registered Debian developers may
- second proposals.
+ Developers may second the issue by emailing a message
+ containing the text "seconded" to the proposal in the
+ BTS. Only registered Debian developers may second proposals.
When a proposal in the BTS has acquired two seconds (apart
from the proposer), it becomes a formal amendment. The bug
severity is raised to "normal" and the bug is retitled to
When a proposal in the BTS has acquired two seconds (apart
from the proposer), it becomes a formal amendment. The bug
severity is raised to "normal" and the bug is retitled to
convince two developers, surely this is not ready for
inclusion in Policy?)</p>
</item>
</enumlist>
</p>
<p>
convince two developers, surely this is not ready for
inclusion in Policy?)</p>
</item>
</enumlist>
</p>
<p>
you wish the proposals to be amended, talk to the proposer,
and get the amendment in. Or else, post an alternative, and
let the group decide which one is better.
you wish the proposals to be amended, talk to the proposer,
and get the amendment in. Or else, post an alternative, and
let the group decide which one is better.
- if the amendment is accepted, the bug is marked
- forwarded and retitled <strong>"[ACCEPTED DD/MM/YYY]..."</strong>.
+ If the amendment is accepted, the bug is marked
+ forwarded and retitled
+ <strong>"[ACCEPTED DD/MM/YYYY] ..."</strong>.
- if the amendment is stalls, or otherwise fails to pass, it
- is retitled as <strong>"[REJECTED DD/MM/YYY] ..."</strong>
+ If the amendment is stalls, or otherwise fails to pass, it
+ is retitled as <strong>"[REJECTED DD/MM/YYYY] ..."</strong>
<heading>Deadlines for Tabling Discussions</heading>
<p>
It has been observed in the past that discussions on the
<heading>Deadlines for Tabling Discussions</heading>
<p>
It has been observed in the past that discussions on the
- mailing list devolve into endless arguments. In order to get
- away from the debating society aspect, at the time of the
- formal proposal, a deadline can be set (probably by the
- proposer, since they are likely to have an idea how
+ mailing list tend to devolve into endless arguments. In
+ order to get away from the debating society aspect, at the
+ time of the formal proposal, a deadline can be set (probably
+ by the proposer, since they are likely to have an idea how
contentious the discussion is likely to be) for ending
discussion on the issue, which should rarely be less than 10
days, and typically two weeks or so. I hope that a hard
contentious the discussion is likely to be) for ending
discussion on the issue, which should rarely be less than 10
days, and typically two weeks or so. I hope that a hard
concluded (in other words, it has not reached an impasse),
and the consensus on the policy group is that an extension
of a week would resolve the issues better, a one-time
concluded (in other words, it has not reached an impasse),
and the consensus on the policy group is that an extension
of a week would resolve the issues better, a one-time
<p>
However, if the issue is non-technical and subjective,
then a vote of the developers may be taken (USENET voting
<p>
However, if the issue is non-technical and subjective,
then a vote of the developers may be taken (USENET voting
and a super-majority of 75% is needed to carry the
amendment through. Failing the super-majority, the issue
should be shelved. It may be re-submitted as a a fresh
and a super-majority of 75% is needed to carry the
amendment through. Failing the super-majority, the issue
should be shelved. It may be re-submitted as a a fresh