diff options
Diffstat (limited to 'debian/data')
36 files changed, 12240 insertions, 0 deletions
diff --git a/debian/data/doc/sisu/v1/markup-samples/samples/_sisu/skin/doc/skin_debian.rb b/debian/data/doc/sisu/v1/markup-samples/samples/_sisu/skin/doc/skin_debian.rb new file mode 100644 index 00000000..bc4008b5 --- /dev/null +++ b/debian/data/doc/sisu/v1/markup-samples/samples/_sisu/skin/doc/skin_debian.rb @@ -0,0 +1,85 @@ +# coding: utf-8 +=begin + * Name: SiSU information Structuring Universe - Serialised information, Structured Units + * Author: Ralph@Amissah.com + * http://www.jus.uio.no/sisu + * http://www.jus.uio.no/sisu/SiSU/download + * Description: Document skin for SiSU descriptive pages, ... + * License: Same as SiSU see http://www.jus.uio.no/sisu + * Notes: Site default appearance variables set in defaults.rb + Generic site wide modifications set here scribe_skin.rb, and this file required by other "scribes" instead of defaults.rb +=end +module SiSU_Viz + require "#{SiSU_lib}/defaults" #<url:zxy_defaults.rb> + class Skin + #% path + def path_root + './sisu/' # the only parameter that cannot be changed here + end + def path_rel + '../' + end + #% url + def url_root_http + 'http://www.jus.uio.no/sisu' + end + def url_home + 'http://www.debian.org/' + end + def url_site # used in pdf header + 'http://www.debian.org' + end + def url_txt # text to go with url usually stripped url + 'www.debian.org' + end + def url_home_url + '../index.html' + end + #% color + def color_band1 + '"#ffffff"' + end + def color_band2 + '"#ffffff"' + end + #% txt + def txt_hp + ' Debian' + end + def txt_home + 'Debian' + end + #% icon + def icon_home_button + 'debian_home.png' + end + def icon_home_banner + home_button + end + #% banner + def banner_home_button + %{<table summary="home button" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/">#{png_home}</a></td></tr></table>\n} + end + def banner_home_and_index_buttons + %{<table><tr><td width="20%"><table summary="home and index buttons" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/" target="_top">#{png_home}</a>#{table_close}</td><td width="60%"><center><center><table summary="buttons" border="1" cellpadding="3" cellspacing="0"><tr><td align="center" bgcolor="#ffffff"><font face="arial" size="2"><a href="toc" target="_top"> This text sub- <br /> Table of Contents </a></font>#{table_close}</center></center></td><td width="20%"> #{table_close}} + end + def banner_band + %{<table summary="band" border="0" cellpadding="3" cellspacing="0"><tr><td align="left" bgcolor="#ffffff"><a href="#{url_site}/" target="_top">#{png_home}</a>#{table_close}} + end + end + class TeX + def header_center + "\\chead{\\href{#{@vz.url_site}/}{www.debian.org}}" + end + def home_url + "\\href{#{@vz.url_site}/}{www.debian.org}" + end + def home + "\\href{#{@vz.url_site}/}{Debian}" + end + def owner_chapter + "Document owner details" + end + end +end + diff --git a/debian/data/doc/sisu/v1/markup-samples/samples/debian_constitution_v1.2.adjusted.sst b/debian/data/doc/sisu/v1/markup-samples/samples/debian_constitution_v1.2.adjusted.sst new file mode 100644 index 00000000..6bd92068 --- /dev/null +++ b/debian/data/doc/sisu/v1/markup-samples/samples/debian_constitution_v1.2.adjusted.sst @@ -0,0 +1,505 @@ +% SiSU 1.0 + +@title: Debian Constitution + +@subtitle: Constitution for the Debian Project (v1.2) [This Document has been Superseded by v1.3] + +@creator: Debian Project + +@type: information + +@subject: debian policy + +@date.created: 1998-12-03 + +@date.issued: 1998-12-03 + +@date.valid: 2003-10-29 + +@date.available: 2003-10-29 + +@date.modified: 2003-10-29 + +@date: 2003-10-29 + +@language.document: English + +@language.original: English + +@level: new=C; num_top=1 + +@skin: skin_debian + +@bold: Debian; DPL + +% @italics: + +@links: {Authoritative Source Document}http://www.debian.org/devel/constitution +{SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html +{SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html +{Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html +{Debian Project}http://www.debian.org/ +{About Debian}http://www.debian.org/intro/about +{News}http://www.debian.org/News/ +{Getting Debian}http://www.debian.org/distrib/ +{Support}http://www.debian.org/support +{Developer's Corner}http://www.debian.org/devel/ +{Site map}http://www.debian.org/sitemap +{Search}http://search.debian.org/ +{License}http://www.debian.org/license + +@rights: http://www.debian.org/license Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/ <br>This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ). <br>"Debian" and the Debian Logo http://www.debian.org/logos/ are trademarks of Software in the Public Interest, Inc. + +@prefix: This Document is Superseded by Version 1.3.<br>This version 1.2 was taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up as a SiSU sample document.<br>Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original + +@rcs: $Id: debian_constitution_v1.2.adjusted.sst,v 1.2 2006/05/24 03:37:02 ralph Exp $ + +:A~ Debian Constitution + +:B~ Constitution for the Debian Project (v1.2) [This Document has been Superseded by v1.3] + +1~pre [Prefix]-# + +Version 1.2 ratified on October 29th, 2003. Supersedes {Version 1.1}http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes {Version 1.0}http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998. + +1~ 1. Introduction + +/{The Debian Project is an association of individuals who have made common cause to create a free operating system.}/ + +This document describes the organisational structure for formal decision-making in the Project. It does not describe the goals of the Project or how it achieves them, or contain any policies except those directly related to the decision-making process. + +1~ 2. Decision-making bodies and individuals + +Each decision in the Project is made by one or more of the following: + +_1 1. The Developers, by way of General Resolution or an election; + +_1 2. The Project Leader; + +_1 3. The Technical Committee and/or its Chairman; + +_1 4. The individual Developer working on a particular task; + +_1 5. Delegates appointed by the Project Leader for specific tasks; + +_1 6. The Project Secretary. + +Most of the remainder of this document will outline the powers of these bodies, their composition and appointment, and the procedure for their decision-making. The powers of a person or body may be subject to review and/or limitation by others; in this case the reviewing body or person's entry will state this. /{In the list above, a person or body is usually listed before any people or bodies whose decisions they can overrule or who they (help) appoint - but not everyone listed earlier can overrule everyone listed later.}/ + +2~ 2.1 General rules + +_1 1. Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not actively work against these rules and decisions properly made under them. + +_1 2. A person may hold several posts, except that the Project Leader, Project Secretary and the Chairman of the Technical Committee must be distinct, and that the Leader cannot appoint themselves as their own Delegate. + +_1 3. A person may leave the Project or resign from a particular post they hold, at any time, by stating so publicly. + +1~ 3 Individual Developers + +2~ 3.1 Powers + +An individual Developer may + +_1 1. make any technical or nontechnical decision with regard to their own work; + +_1 2. propose or sponsor draft General Resolutions; + +_1 3. propose themselves as a Project Leader candidate in elections; + +_1 4. vote on General Resolutions and in Leadership elections. + +2~ 3.2 Composition and appointment + +_1 1. Developers are volunteers who agree to further the aims of the Project insofar as they participate in it, and who maintain package(s) for the Project or do other work which the Project Leader's Delegate(s) consider worthwhile. + +_1 2. The Project Leader's Delegate(s) may choose not to admit new Developers, or expel existing Developers. /{If the Developers feel that the Delegates are abusing their authority they can of course override the decision by way of General Resolution - see §4.1(3), §4.2.}/ + +2~ 3.3 Procedure + +Developers may make these decisions as they see fit. + +1~ 4. The Developers by way of General Resolution or election + +2~ 4.1 Powers + +Together, the Developers may: + +_1 1. Appoint or recall the Project Leader. + +_1 2. Amend this constitution, provided they agree with a 3:1 majority. + +_1 3. Override any decision by the Project Leader or a Delegate. + +_1 4. Override any decision by the Technical Committee, provided they agree with a 2:1 majority. + +_1 5. Issue, supersede and withdraw nontechnical policy documents and statements. + +These include documents describing the goals of the project, its relationship with other free software entities, and nontechnical policies such as the free software licence terms that Debian software must meet. + +They may also include position statements about issues of the day. + +_2 1. A Foundation Document is a document or statement regarded as critical to the Project's mission and purposes. + +_2 2. The Foundation Documents are the works entitled Debian Social Contract and Debian Free Software Guidelines. + +_2 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. + +_1 6. Together with the Project Leader and SPI, make decisions about property held in trust for purposes related to Debian. (See §9.1.) + +2~ 4.2 Procedure + +_1 1. The Developers follow the Standard Resolution Procedure, below. A resolution or amendment is introduced if proposed by any Developer and sponsored by at least K other Developers, or if proposed by the Project Leader or the Technical Committee. + +_1 2. Delaying a decision by the Project Leader or their Delegate: + +_2 1. If the Project Leader or their Delegate, or the Technical Committee, has made a decision, then Developers can override them by passing a resolution to do so; see s4.1(3). + +_2 2. If such a resolution is sponsored by at least 2K Developers, or if it is proposed by the Technical Committee, the resolution puts the decision immediately on hold (provided that resolution itself says so). + +_2 3. If the original decision was to change a discussion period or a voting period, or the resolution is to override the Technical Committee, then only K Developers need to sponsor the resolution to be able to put the decision immediately on hold. + +_2 4. If the decision is put on hold, an immediate vote is held to determine whether the decision will stand until the full vote on the decision is made or whether the implementation of the original decision will be delayed until then. There is no quorum for this immediate procedural vote. + +_2 5. If the Project Leader (or the Delegate) withdraws the original decision, the vote becomes moot, and is no longer conducted. + +_1 3. Votes are taken by the Project Secretary. Votes, tallies, and results are not revealed during the voting period; after the vote the Project Secretary lists all the votes cast. The voting period is 2 weeks, but may be varied by up to 1 week by the Project Leader. + +_1 4. The minimum discussion period is 2 weeks, but may be varied by up to 1 week by the Project Leader. The Project Leader has a casting vote. There is a quorum of 3Q. + +_1 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. + +_1 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. + +_1 7. Q is half of the square root of the number of current Developers. K is Q or 5, whichever is the smaller. Q and K need not be integers and are not rounded. + +1~ 5. Project Leader + +2~ 5.1 Powers + +The {Project Leader}http://www.debian.org/devel/leader may: + +_1 1. Appoint Delegates or delegate decisions to the Technical Committee. + +_1 The Leader may define an area of ongoing responsibility or a specific decision and hand it over to another Developer or to the Technical Committee. + +_1 Once a particular decision has been delegated and made the Project Leader may not withdraw that delegation; however, they may withdraw an ongoing delegation of particular area of responsibility. + +_1 2. Lend authority to other Developers. + +_1 The Project Leader may make statements of support for points of view or for other members of the project, when asked or otherwise; these statements have force if and only if the Leader would be empowered to make the decision in question. + +_1 3. Make any decision which requires urgent action. + +_1 This does not apply to decisions which have only become gradually urgent through lack of relevant action, unless there is a fixed deadline. + +_1 4. Make any decision for whom noone else has responsibility. + +_1 5. Propose draft General Resolutions and amendments. + +_1 6. Together with the Technical Committee, appoint new members to the Committee. (See §6.2.) + +_1 7. Use a casting vote when Developers vote. + +_1 The Project Leader also has a normal vote in such ballots. + +_1 8. Vary the discussion period for Developers' votes (as above). + +_1 9. Lead discussions amongst Developers. + +_1 The Project Leader should attempt to participate in discussions amongst the Developers in a helpful way which seeks to bring the discussion to bear on the key issues at hand. The Project Leader should not use the Leadership position to promote their own personal views. + +_1 10. Together with SPI, make decisions affecting property held in trust for purposes related to Debian. (See §9.1.) + +2~ 5.2 Appointment + +_1 1. The Project Leader is elected by the Developers. + +_1 2. The election begins nine weeks before the leadership post becomes vacant, or (if it is too late already) immediately. + +_1 3. For the following three weeks any Developer may nominate themselves as a candidate Project Leader. + +_1 4. For three weeks after that no more candidates may be nominated; candidates should use this time for campaigning (to make their identities and positions known). If there are no candidates at the end of the nomination period then the nomination period is extended for three further weeks, repeatedly if necessary. + +_1 5. The next three weeks are the polling period during which Developers may cast their votes. Votes in leadership elections are kept secret, even after the election is finished. + +_1 6. The options on the ballot will be those candidates who have nominated themselves and have not yet withdrawn, plus None Of The Above. If None Of The Above wins the election then the election procedure is repeated, many times if necessary. + +_1 7. The decision will be made using the method specified in section §A.6 of the Standard Resolution Procedure. The quorum is the same as for a General Resolution (§4.2) and the default option is "None Of The Above". + +_1 8. The Project Leader serves for one year from their election. + +2~ 5.3 Procedure + +The Project Leader should attempt to make decisions which are consistent with the consensus of the opinions of the Developers. + +Where practical the Project Leader should informally solicit the views of the Developers. + +The Project Leader should avoid overemphasizing their own point of view when making decisions in their capacity as Leader. + +1~ 6. Technical committee + +2~ 6.1 Powers + +The {Technical Committee}http://www.debian.org/devel/tech-ctte may: + +_1 1. Decide on any matter of technical policy. + +_1 This includes the contents of the technical policy manuals, developers' reference materials, example packages and the behaviour of non-experimental package building tools. (In each case the usual maintainer of the relevant software or documentation makes decisions initially, however; see 6.3(5).) + +_1 2. Decide any technical matter where Developers' jurisdictions overlap. + +_1 In cases where Developers need to implement compatible technical policies or stances (for example, if they disagree about the priorities of conflicting packages, or about ownership of a command name, or about which package is responsible for a bug that both maintainers agree is a bug, or about who should be the maintainer for a package) the technical committee may decide the matter. + +_1 3. Make a decision when asked to do so. + +_1 Any person or body may delegate a decision of their own to the Technical Committee, or seek advice from it. + +_1 4. Overrule a Developer (requires a 3:1 majority). + +_1 The Technical Committee may ask a Developer to take a particular technical course of action even if the Developer does not wish to; this requires a 3:1 majority. For example, the Committee may determine that a complaint made by the submitter of a bug is justified and that the submitter's proposed solution should be implemented. + +_1 5. Offer advice. + +_1 The Technical Committee may make formal announcements about its views on any matter. Individual members may of course make informal statements about their views and about the likely views of the committee. + +_1 6. Together with the Project Leader, appoint new members to itself or remove existing members. (See §6.2.) + +_1 7. Appoint the Chairman of the Technical Committee. + +_1 The Chairman is elected by the Committee from its members. All members of the committee are automatically nominated; the committee votes starting one week before the post will become vacant (or immediately, if it is already too late). The members may vote by public acclamation for any fellow committee member, including themselves; there is no default option. The vote finishes when all the members have voted, or when the voting period has ended. The result is determined using the method specified in section A.6 of the Standard Resolution Procedure. + +_1 8. The Chairman can stand in for the Leader, together with the Secretary + +_1 As detailed in §7.1(2), the Chairman of the Technical Committee and the Project Secretary may together stand in for the Leader if there is no Leader. + +2~ 6.2 Composition + +_1 1. The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members. + +_1 2. When there are fewer than 8 members the Technical Committee may recommend new member(s) to the Project Leader, who may choose (individually) to appoint them or not. + +_1 3. When there are 5 members or fewer the Technical Committee may appoint new member(s) until the number of members reaches 6. + +_1 4. When there have been 5 members or fewer for at least one week the Project Leader may appoint new member(s) until the number of members reaches 6, at intervals of at least one week per appointment. + +_1 5. If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee. + +2~ 5.3 Procedure + +_1 1. The Technical Committee uses the Standard Resolution Procedure. + +_1 A draft resolution or amendment may be proposed by any member of the Technical Committee. There is no minimum discussion period; the voting period lasts for up to one week, or until the outcome is no longer in doubt. Members may change their votes. There is a quorum of two. + +_1 2. Details regarding voting + +_1 The Chairman has a casting vote. When the Technical Committee votes whether to override a Developer who also happens to be a member of the Committee, that member may not vote (unless they are the Chairman, in which case they may use only their casting vote). + +_1 3. Public discussion and decision-making. + +_1 Discussion, draft resolutions and amendments, and votes by members of the committee, are made public on the Technical Committee public discussion list. There is no separate secretary for the Committee. + +_1 4. Confidentiality of appointments. + +_1 The Technical Committee may hold confidential discussions via private email or a private mailing list or other means to discuss appointments to the Committee. However, votes on appointments must be public. + +_1 5. No detailed design work. + +_1 The Technical Committee does not engage in design of new proposals and policies. Such design work should be carried out by individuals privately or together and discussed in ordinary technical policy and design forums. + +_1 The Technical Committee restricts itself to choosing from or adopting compromises between solutions and decisions which have been proposed and reasonably thoroughly discussed elsewhere. + +_1 /{Individual members of the technical committee may of course participate on their own behalf in any aspect of design and policy work.}/ + +_1 6. Technical Committee makes decisions only as last resort. + +_1 The Technical Committee does not make a technical decision until efforts to resolve it via consensus have been tried and failed, unless it has been asked to make a decision by the person or body who would normally be responsible for it. + +1~ 7. The Project Secretary + +2~ 7.1 Powers + +The {Secretary:}http://www.debian.org/devel/secretary + +_1 1. Takes votes amongst the Developers, and determines the number and identity of Developers, whenever this is required by the constitution. + +_1 2. Can stand in for the Leader, together with the Chairman of the Technical Committee. + +_1 If there is no Project Leader then the Chairman of the Technical Committee and the Project Secretary may by joint agreement make decisions if they consider it imperative to do so. + +_1 3. Adjudicates any disputes about interpretation of the constitution. + +_1 4. May delegate part or all of their authority to someone else, or withdraw such a delegation at any time. + +2~ 7.2 Appointment + +The Project Secretary is appointed by the Project Leader and the current Project Secretary. + +If the Project Leader and the current Project Secretary cannot agree on a new appointment they must ask the board of SPI (see §9.1.) to appoint a Secretary. + +If there is no Project Secretary or the current Secretary is unavailable and has not delegated authority for a decision then the decision may be made or delegated by the Chairman of the Technical Committee, as Acting Secretary. + +The Project Secretary's term of office is 1 year, at which point they or another Secretary must be (re)appointed. + +2~ 7.3 Procedure + +The Project Secretary should make decisions which are fair and reasonable, and preferably consistent with the consensus of the Developers. + +When acting together to stand in for an absent Project Leader the Chairman of the Technical Committee and the Project Secretary should make decisions only when absolutely necessary and only when consistent with the consensus of the Developers. + +1~ 8. The Project Leader's Delegates + +2~ 8.1 Powers + +The Project Leader's Delegates: + +_1 1. have powers delegated to them by the Project Leader; + +_1 2. may make certain decisions which the Leader may not make directly, including approving or expelling Developers or designating people as Developers who do not maintain packages. This is to avoid concentration of power, particularly over membership as a Developer, in the hands of the Project Leader. + +2~ 8.2 Appointment + +The Delegates are appointed by the Project Leader and may be replaced by the Leader at the Leader's discretion. The Project Leader may not make the position as a Delegate conditional on particular decisions by the Delegate, nor may they override a decision made by a Delegate once made. + +2~ 8.3 Procedure + +Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion. + +1~ 9. Software in the Public Interest + +{SPI}http://www.spi-inc.org/ and Debian are separate organisations who share some goals. Debian is grateful for the legal support framework offered by SPI. Debian's Developers are currently members of SPI by virtue of their status as Developers. + +2~ 9.1 Authority + +_1 1. SPI has no authority regarding Debian's technical or nontechnical decisions, except that no decision by Debian with respect to any property held by SPI shall require SPI to act outside its legal authority, and that Debian's constitution may occasionally use SPI as a decision body of last resort. + +_1 2. Debian claims no authority over SPI other than that over the use of certain of SPI's property, as described below, though Debian Developers may be granted authority within SPI by SPI's rules. + +_1 3. Debian Developers are not agents or employees of SPI, or of each other or of persons in authority in the Debian Project. A person acting as a Developer does so as an individual, on their own behalf. + +2~ 9.2 Management of property for purposes related to Debian + +Since Debian has no authority to hold money or property, any donations for the Debian Project must be made to SPI, which manages such affairs. + +SPI have made the following undertakings: + +_1 1. SPI will hold money, trademarks and other tangible and intangible property and manage other affairs for purposes related to Debian. + +_1 2. Such property will be accounted for separately and held in trust for those purposes, decided on by Debian and SPI according to this section. + +_1 3. SPI will not dispose of or use property held in trust for Debian without approval from Debian, which may be granted by the Project Leader or by General Resolution of the Developers. + +_1 4. SPI will consider using or disposing of property held in trust for Debian when asked to do so by the Project Leader. + +_1 5. SPI will use or dispose of property held in trust for Debian when asked to do so by a General Resolution of the Developers, provided that this is compatible with SPI's legal authority. + +_1 6. SPI will notify the Developers by electronic mail to a Debian Project mailing list when it uses or disposes of property held in trust for Debian. + +1~a A. Standard Resolution Procedure + +These rules apply to communal decision-making by committees and plebiscites, where stated above. + +2~a1 A.1. Proposal + +The formal procedure begins when a draft resolution is proposed and sponsored, as required. + +2~a1a A.1 Discussion and Amendment + +_1 1. Following the proposal, the resolution may be discussed. Amendments may be made formal by being proposed and sponsored according to the requirements for a new resolution, or directly by the proposer of the original resolution. + +_1 2. A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match. + +_1 3. If a formal amendment is not accepted, or one of the sponsors of the resolution does not agree with the acceptance by the proposer of a formal amendment, the amendment remains as an amendment and will be voted on. + +_1 4. If an amendment accepted by the original proposer is not to the liking of others, they may propose another amendment to reverse the earlier change (again, they must meet the requirements for proposer and sponsor(s).) + +_1 5. The proposer or 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. + +_1 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 noone objects within 24 hours. In this case the minimum discussion period is not restarted. + +2~a2 A.2. Calling for a vote + +_1 1. The proposer or a sponsor of a motion or an amendment may call for a vote, providing that the minimum discussion period (if any) has elapsed. + +_1 2. The proposer or any sponsor of a resolution may call for a vote on that resolution and all related amendments. + +_1 3. The person who calls for a vote states what they believe the wordings of the resolution and any relevant amendments are, and consequently what form the ballot should take. However, the final decision on the form of ballot(s) is the Secretary's - see 7.1(1), 7.1(3) and A.3(4). + +_1 4. The minimum discussion period is counted from the time the last formal amendment was accepted, or since the whole resolution was proposed if no amendments have been proposed and accepted. + +2~a3 A.3. Voting procedure + +_1 1. Each resolution and its related amendments is voted on in a single ballot that includes an option for the original resolution, each amendment, and the default option (where applicable). + +_1 2. The default option must not have any supermajority requirements. Options which do not have an explicit supermajority requirement have a 1:1 majority requirement. + +_1 3. The votes are counted according to the rules in A.6. The default option is "Further Discussion", unless specified otherwise. + +_1 4. In cases of doubt the Project Secretary shall decide on matters of procedure. + +2~a4 A.4. Withdrawing resolutions or unaccepted amendments + +The proposer of a resolution or unaccepted amendment may withdraw it. In this case new proposers may come forward keep it alive, in which case the first person to do so becomes the new proposer and any others become sponsors if they aren't sponsors already. + +A sponsor of a resolution or amendment (unless it has been accepted) may withdraw. + +If the withdrawal of the proposer and/or sponsors means that a resolution has no proposer or not enough sponsors it will not be voted on unless this is rectified before the resolution expires. + +2~a5 A.5. Expiry + +If a proposed resolution has not been discussed, amended, voted on or otherwise dealt with for 4 weeks the secretary may issue a statement that the issue is being withdrawn. If none of the sponsors of any of the proposals object within a week, the issue is withdrawn. + +The secretary may also include suggestions on how to proceed, if appropriate. + +2~a6 A.6. Vote Counting + +_1 1. Each voter's ballot ranks the options being voted on. Not all options need be ranked. Ranked options are considered preferred to all unranked options. Voters may rank options equally. Unranked options are considered to be ranked equally with one another. Details of how ballots may be filled out will be included in the Call For Votes. + +_1 2. If the ballot has a quorum requirement R any options other than the default option which do not receive at least R votes ranking that option above the default option are dropped from consideration. + +_1 3. Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration. + +_2 1. Given two options A and B, V(A,B) is the number of voters who prefer option A over option B. + +_2 2. An option A defeats the default option D by a majority ratio N, if V(A,D) is strictly greater than N * V(D,A). + +_2 3. If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1. + +_1 4. From the list of undropped options, we generate a list of pairwise defeats. + +_1 1. An option A defeats an option B, if V(A,B) is strictly greater than V(B,A). + +_1 5. From the list of [undropped] pairwise defeats, we generate a set of transitive defeats. + +_1 1. An option A transitively defeats an option C if A defeats C or if there is some other option B where A defeats B AND B transitively defeats C. + +_1 6. We construct the Schwartz set from the set of transitive defeats. + +_2 1. An option A is in the Schwartz set if for all options B, either A transitively defeats B, or B does not transitively defeat A. + +_1 7. If there are defeats between options in the Schwartz set, we drop the weakest such defeats from the list of pairwise defeats, and return to step 5. + +_2 1. A defeat (A,X) is weaker than a defeat (B,Y) if V(A,X) is less than V(B,Y). Also, (A,X) is weaker than (B,Y) if V(A,X) is equal to V(B,Y) and V(X,A) is greater than V(Y,B). + +_2 2. A weakest defeat is a defeat that has no other defeat weaker than it. There may be more than one such defeat. + +_1 8. If there are no defeats within the Schwartz set, then the winner is chosen from the options in the Schwartz set. If there is only one such option, it is the winner. If there are multiple options, the elector with the casting vote chooses which of those options wins. + +!_ Note: +Options which the voters rank above the default option are options they find acceptable. Options ranked below the default options are options they find unacceptable. + +/{When the Standard Resolution Procedure is to be used, the text which refers to it must specify what is sufficient to have a draft resolution proposed and/or sponsored, what the minimum discussion period is, and what the voting period is. It must also specify any supermajority and/or the quorum (and default option) to be used.}/ + +2~b B. Use of language and typography + +The present indicative ('is', for example) means that the statement is a rule in this constitution. 'May' or 'can' indicates that the person or body has discretion. 'Should' means that it would be considered a good thing if the sentence were obeyed, but it is not binding. Text marked as a citation, such as this, is rationale and does not form part of the constitution. It may be used only to aid interpretation in cases of doubt. + +%% SiSU markup sample Notes: +% SiSU http://www.jus.uio.no/sisu +% SiSU markup for 0.16 and later: +% 0.20.4 header 0~links +% 0.22 may drop image dimensions (rmagick) +% 0.23 utf-8 ß +% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title) +% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6 +% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html +% markup in this document is 0.38, (rad) experimental diff --git a/debian/data/doc/sisu/v1/markup-samples/samples/debian_constitution_v1.2.sst b/debian/data/doc/sisu/v1/markup-samples/samples/debian_constitution_v1.2.sst new file mode 100644 index 00000000..1b3396f3 --- /dev/null +++ b/debian/data/doc/sisu/v1/markup-samples/samples/debian_constitution_v1.2.sst @@ -0,0 +1,502 @@ +% SiSU 1.0 + +@title: Debian Constitution + +@subtitle: Constitution for the Debian Project (v1.2) [This Document has been Superseded by v1.3] + +@creator: Debian Project + +@type: information + +@subject: debian policy + +@date.created: 1998-12-03 + +@date.issued: 1998-12-03 + +@date.valid: 2003-10-29 + +@date.available: 2003-10-29 + +@date.modified: 2003-10-29 + +@date: 2003-10-29 + +@language.document: English + +@language.original: English + +@level: new=C; num_top=1 + +@skin: skin_debian + +@bold: Debian; DPL + +% @italics: + +@rights: http://www.debian.org/license Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/ <br>This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ). <br>"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc. + +@links: {Authoritative Source Document}http://www.debian.org/devel/constitution +{SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html +{SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html +{Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html +{About Debian}http://www.debian.org/intro/about +{News}http://www.debian.org/News/ +{Getting Debian}http://www.debian.org/distrib/ +{Support}http://www.debian.org/support +{Developer's Corner}http://www.debian.org/devel/ +{Sitemap}http://www.debian.org/sitemap +{Search}http://search.debian.org/ + +@prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.<br>Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original + +@rcs: $Id: debian_constitution_v1.2.s3,v 1.7 2006/02/28 12:11:55 ralph Exp $ + +:A~ Debian Constitution + +:B~ Constitution for the Debian Project (v1.2) [This Document has been Superseded by v1.3] + +1~pre [Prefix]-# + +Version 1.2 ratified on October 29th, 2003. Supersedes {Version 1.1}http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes {Version 1.0}http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998. + +1~ Introduction + +/{The Debian Project is an association of individuals who have made common cause to create a free operating system.}/ + +This document describes the organisational structure for formal decision-making in the Project. It does not describe the goals of the Project or how it achieves them, or contain any policies except those directly related to the decision-making process. + +1~ Decision-making bodies and individuals + +Each decision in the Project is made by one or more of the following: + +# The Developers, by way of General Resolution or an election; + +# The Project Leader; + +# The Technical Committee and/or its Chairman; + +# The individual Developer working on a particular task; + +# Delegates appointed by the Project Leader for specific tasks; + +# The Project Secretary. + +Most of the remainder of this document will outline the powers of these bodies, their composition and appointment, and the procedure for their decision-making. The powers of a person or body may be subject to review and/or limitation by others; in this case the reviewing body or person's entry will state this. /{In the list above, a person or body is usually listed before any people or bodies whose decisions they can overrule or who they (help) appoint - but not everyone listed earlier can overrule everyone listed later.}/ + +2~ General rules + +# Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not actively work against these rules and decisions properly made under them. + +# A person may hold several posts, except that the Project Leader, Project Secretary and the Chairman of the Technical Committee must be distinct, and that the Leader cannot appoint themselves as their own Delegate. + +# A person may leave the Project or resign from a particular post they hold, at any time, by stating so publicly. + +1~ Individual Developers + +2~ Powers + +An individual Developer may + +# make any technical or nontechnical decision with regard to their own work; + +# propose or sponsor draft General Resolutions; + +# propose themselves as a Project Leader candidate in elections; + +# vote on General Resolutions and in Leadership elections. + +2~ Composition and appointment + +# Developers are volunteers who agree to further the aims of the Project insofar as they participate in it, and who maintain package(s) for the Project or do other work which the Project Leader's Delegate(s) consider worthwhile. + +# The Project Leader's Delegate(s) may choose not to admit new Developers, or expel existing Developers. /{If the Developers feel that the Delegates are abusing their authority they can of course override the decision by way of General Resolution - see §4.1(3), §4.2.}/ + +2~ Procedure + +Developers may make these decisions as they see fit. + +1~ The Developers by way of General Resolution or election + +2~ Powers + +Together, the Developers may: + +# Appoint or recall the Project Leader. + +# Amend this constitution, provided they agree with a 3:1 majority. + +# Override any decision by the Project Leader or a Delegate. + +# Override any decision by the Technical Committee, provided they agree with a 2:1 majority. + +# Issue, supersede and withdraw nontechnical policy documents and statements. + +These include documents describing the goals of the project, its relationship with other free software entities, and nontechnical policies such as the free software licence terms that Debian software must meet. + +They may also include position statements about issues of the day. + +_# A Foundation Document is a document or statement regarded as critical to the Project's mission and purposes. + +_# The Foundation Documents are the works entitled Debian Social Contract and Debian Free Software Guidelines. + +_# 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. + +# Together with the Project Leader and SPI, make decisions about property held in trust for purposes related to Debian. (See §9.1.) + +2~ Procedure + +# The Developers follow the Standard Resolution Procedure, below. A resolution or amendment is introduced if proposed by any Developer and sponsored by at least K other Developers, or if proposed by the Project Leader or the Technical Committee. + +# Delaying a decision by the Project Leader or their Delegate: + +_# If the Project Leader or their Delegate, or the Technical Committee, has made a decision, then Developers can override them by passing a resolution to do so; see s4.1(3). + +_# If such a resolution is sponsored by at least 2K Developers, or if it is proposed by the Technical Committee, the resolution puts the decision immediately on hold (provided that resolution itself says so). + +_# If the original decision was to change a discussion period or a voting period, or the resolution is to override the Technical Committee, then only K Developers need to sponsor the resolution to be able to put the decision immediately on hold. + +_# If the decision is put on hold, an immediate vote is held to determine whether the decision will stand until the full vote on the decision is made or whether the implementation of the original decision will be delayed until then. There is no quorum for this immediate procedural vote. + +_# If the Project Leader (or the Delegate) withdraws the original decision, the vote becomes moot, and is no longer conducted. + +# Votes are taken by the Project Secretary. Votes, tallies, and results are not revealed during the voting period; after the vote the Project Secretary lists all the votes cast. The voting period is 2 weeks, but may be varied by up to 1 week by the Project Leader. + +# The minimum discussion period is 2 weeks, but may be varied by up to 1 week by the Project Leader. The Project Leader has a casting vote. There is a quorum of 3Q. + +# 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. + +# Votes are cast by email in a manner suitable to the Secretary. The Secretary determines for each poll whether voters can change their votes. + +# Q is half of the square root of the number of current Developers. K is Q or 5, whichever is the smaller. Q and K need not be integers and are not rounded. + +1~ Project Leader + +2~ Powers + +The {Project Leader}http://www.debian.org/devel/leader may: + +# Appoint Delegates or delegate decisions to the Technical Committee. + +The Leader may define an area of ongoing responsibility or a specific decision and hand it over to another Developer or to the Technical Committee. + +Once a particular decision has been delegated and made the Project Leader may not withdraw that delegation; however, they may withdraw an ongoing delegation of particular area of responsibility. + +# Lend authority to other Developers. + +The Project Leader may make statements of support for points of view or for other members of the project, when asked or otherwise; these statements have force if and only if the Leader would be empowered to make the decision in question. + +# Make any decision which requires urgent action. + +This does not apply to decisions which have only become gradually urgent through lack of relevant action, unless there is a fixed deadline. + +# Make any decision for whom noone else has responsibility. + +# Propose draft General Resolutions and amendments. + +# Together with the Technical Committee, appoint new members to the Committee. (See §6.2.) + +# Use a casting vote when Developers vote. + +The Project Leader also has a normal vote in such ballots. + +# Vary the discussion period for Developers' votes (as above). + +# Lead discussions amongst Developers. + +The Project Leader should attempt to participate in discussions amongst the Developers in a helpful way which seeks to bring the discussion to bear on the key issues at hand. The Project Leader should not use the Leadership position to promote their own personal views. + +# Together with SPI, make decisions affecting property held in trust for purposes related to Debian. (See §9.1.) + +2~ Appointment + +# The Project Leader is elected by the Developers. + +# The election begins nine weeks before the leadership post becomes vacant, or (if it is too late already) immediately. + +# For the following three weeks any Developer may nominate themselves as a candidate Project Leader. + +# For three weeks after that no more candidates may be nominated; candidates should use this time for campaigning (to make their identities and positions known). If there are no candidates at the end of the nomination period then the nomination period is extended for three further weeks, repeatedly if necessary. + +# The next three weeks are the polling period during which Developers may cast their votes. Votes in leadership elections are kept secret, even after the election is finished. + +# The options on the ballot will be those candidates who have nominated themselves and have not yet withdrawn, plus None Of The Above. If None Of The Above wins the election then the election procedure is repeated, many times if necessary. + +# The decision will be made using the method specified in section §A.6 of the Standard Resolution Procedure. The quorum is the same as for a General Resolution (§4.2) and the default option is "None Of The Above". + +# The Project Leader serves for one year from their election. + +2~ Procedure + +The Project Leader should attempt to make decisions which are consistent with the consensus of the opinions of the Developers. + +Where practical the Project Leader should informally solicit the views of the Developers. + +The Project Leader should avoid overemphasizing their own point of view when making decisions in their capacity as Leader. + +1~ Technical committee + +2~ Powers + +The {Technical Committee}http://www.debian.org/devel/tech-ctte may: + +# Decide on any matter of technical policy. + +This includes the contents of the technical policy manuals, developers' reference materials, example packages and the behaviour of non-experimental package building tools. (In each case the usual maintainer of the relevant software or documentation makes decisions initially, however; see 6.3(5).) + +# Decide any technical matter where Developers' jurisdictions overlap. + +In cases where Developers need to implement compatible technical policies or stances (for example, if they disagree about the priorities of conflicting packages, or about ownership of a command name, or about which package is responsible for a bug that both maintainers agree is a bug, or about who should be the maintainer for a package) the technical committee may decide the matter. + +# Make a decision when asked to do so. + +Any person or body may delegate a decision of their own to the Technical Committee, or seek advice from it. + +# Overrule a Developer (requires a 3:1 majority). + +The Technical Committee may ask a Developer to take a particular technical course of action even if the Developer does not wish to; this requires a 3:1 majority. For example, the Committee may determine that a complaint made by the submitter of a bug is justified and that the submitter's proposed solution should be implemented. + +# Offer advice. + +The Technical Committee may make formal announcements about its views on any matter. Individual members may of course make informal statements about their views and about the likely views of the committee. + +# Together with the Project Leader, appoint new members to itself or remove existing members. (See §6.2.) + +# Appoint the Chairman of the Technical Committee. + +The Chairman is elected by the Committee from its members. All members of the committee are automatically nominated; the committee votes starting one week before the post will become vacant (or immediately, if it is already too late). The members may vote by public acclamation for any fellow committee member, including themselves; there is no default option. The vote finishes when all the members have voted, or when the voting period has ended. The result is determined using the method specified in section A.6 of the Standard Resolution Procedure. + +# The Chairman can stand in for the Leader, together with the Secretary + +As detailed in §7.1(2), the Chairman of the Technical Committee and the Project Secretary may together stand in for the Leader if there is no Leader. + +2~ Composition + +# The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members. + +# When there are fewer than 8 members the Technical Committee may recommend new member(s) to the Project Leader, who may choose (individually) to appoint them or not. + +# When there are 5 members or fewer the Technical Committee may appoint new member(s) until the number of members reaches 6. + +# When there have been 5 members or fewer for at least one week the Project Leader may appoint new member(s) until the number of members reaches 6, at intervals of at least one week per appointment. + +# If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee. + +2~ Procedure + +# The Technical Committee uses the Standard Resolution Procedure. + +A draft resolution or amendment may be proposed by any member of the Technical Committee. There is no minimum discussion period; the voting period lasts for up to one week, or until the outcome is no longer in doubt. Members may change their votes. There is a quorum of two. + +# Details regarding voting + +The Chairman has a casting vote. When the Technical Committee votes whether to override a Developer who also happens to be a member of the Committee, that member may not vote (unless they are the Chairman, in which case they may use only their casting vote). + +# Public discussion and decision-making. + +Discussion, draft resolutions and amendments, and votes by members of the committee, are made public on the Technical Committee public discussion list. There is no separate secretary for the Committee. + +# Confidentiality of appointments. + +The Technical Committee may hold confidential discussions via private email or a private mailing list or other means to discuss appointments to the Committee. However, votes on appointments must be public. + +# No detailed design work. + +The Technical Committee does not engage in design of new proposals and policies. Such design work should be carried out by individuals privately or together and discussed in ordinary technical policy and design forums. + +The Technical Committee restricts itself to choosing from or adopting compromises between solutions and decisions which have been proposed and reasonably thoroughly discussed elsewhere. + +/{Individual members of the technical committee may of course participate on their own behalf in any aspect of design and policy work.}/ + +# Technical Committee makes decisions only as last resort. + +The Technical Committee does not make a technical decision until efforts to resolve it via consensus have been tried and failed, unless it has been asked to make a decision by the person or body who would normally be responsible for it. + +1~ The Project Secretary + +2~ Powers + +The {Secretary:}http://www.debian.org/devel/secretary + +# Takes votes amongst the Developers, and determines the number and identity of Developers, whenever this is required by the constitution. + +# Can stand in for the Leader, together with the Chairman of the Technical Committee. + +If there is no Project Leader then the Chairman of the Technical Committee and the Project Secretary may by joint agreement make decisions if they consider it imperative to do so. + +# Adjudicates any disputes about interpretation of the constitution. + +# May delegate part or all of their authority to someone else, or withdraw such a delegation at any time. + +2~ Appointment + +The Project Secretary is appointed by the Project Leader and the current Project Secretary. + +If the Project Leader and the current Project Secretary cannot agree on a new appointment they must ask the board of SPI (see §9.1.) to appoint a Secretary. + +If there is no Project Secretary or the current Secretary is unavailable and has not delegated authority for a decision then the decision may be made or delegated by the Chairman of the Technical Committee, as Acting Secretary. + +The Project Secretary's term of office is 1 year, at which point they or another Secretary must be (re)appointed. + +2~ Procedure + +The Project Secretary should make decisions which are fair and reasonable, and preferably consistent with the consensus of the Developers. + +When acting together to stand in for an absent Project Leader the Chairman of the Technical Committee and the Project Secretary should make decisions only when absolutely necessary and only when consistent with the consensus of the Developers. + +1~ The Project Leader's Delegates + +2~ Powers + +The Project Leader's Delegates: + +# have powers delegated to them by the Project Leader; + +# may make certain decisions which the Leader may not make directly, including approving or expelling Developers or designating people as Developers who do not maintain packages. This is to avoid concentration of power, particularly over membership as a Developer, in the hands of the Project Leader. + +2~ Appointment + +The Delegates are appointed by the Project Leader and may be replaced by the Leader at the Leader's discretion. The Project Leader may not make the position as a Delegate conditional on particular decisions by the Delegate, nor may they override a decision made by a Delegate once made. + +2~ Procedure + +Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion. + +1~ Software in the Public Interest + +{SPI}http://www.spi-inc.org/ and Debian are separate organisations who share some goals. Debian is grateful for the legal support framework offered by SPI. Debian's Developers are currently members of SPI by virtue of their status as Developers. + +2~ Authority + +# SPI has no authority regarding Debian's technical or nontechnical decisions, except that no decision by Debian with respect to any property held by SPI shall require SPI to act outside its legal authority, and that Debian's constitution may occasionally use SPI as a decision body of last resort. + +# Debian claims no authority over SPI other than that over the use of certain of SPI's property, as described below, though Debian Developers may be granted authority within SPI by SPI's rules. + +# Debian Developers are not agents or employees of SPI, or of each other or of persons in authority in the Debian Project. A person acting as a Developer does so as an individual, on their own behalf. + +2~ Management of property for purposes related to Debian + +Since Debian has no authority to hold money or property, any donations for the Debian Project must be made to SPI, which manages such affairs. + +SPI have made the following undertakings: + +# SPI will hold money, trademarks and other tangible and intangible property and manage other affairs for purposes related to Debian. + +# Such property will be accounted for separately and held in trust for those purposes, decided on by Debian and SPI according to this section. + +# SPI will not dispose of or use property held in trust for Debian without approval from Debian, which may be granted by the Project Leader or by General Resolution of the Developers. + +# SPI will consider using or disposing of property held in trust for Debian when asked to do so by the Project Leader. + +# SPI will use or dispose of property held in trust for Debian when asked to do so by a General Resolution of the Developers, provided that this is compatible with SPI's legal authority. + +# SPI will notify the Developers by electronic mail to a Debian Project mailing list when it uses or disposes of property held in trust for Debian. + +1~a A. Standard Resolution Procedure + +These rules apply to communal decision-making by committees and plebiscites, where stated above. + +2~a1 A.1. Proposal + +The formal procedure begins when a draft resolution is proposed and sponsored, as required. + +2~a1a A.1 Discussion and Amendment + +# Following the proposal, the resolution may be discussed. Amendments may be made formal by being proposed and sponsored according to the requirements for a new resolution, or directly by the proposer of the original resolution. + +# A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match. + +# If a formal amendment is not accepted, or one of the sponsors of the resolution does not agree with the acceptance by the proposer of a formal amendment, the amendment remains as an amendment and will be voted on. + +# If an amendment accepted by the original proposer is not to the liking of others, they may propose another amendment to reverse the earlier change (again, they must meet the requirements for proposer and sponsor(s).) + +# The proposer or 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. + +# 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 noone objects within 24 hours. In this case the minimum discussion period is not restarted. + +2~a2 A.2. Calling for a vote + +# The proposer or a sponsor of a motion or an amendment may call for a vote, providing that the minimum discussion period (if any) has elapsed. + +# The proposer or any sponsor of a resolution may call for a vote on that resolution and all related amendments. + +# The person who calls for a vote states what they believe the wordings of the resolution and any relevant amendments are, and consequently what form the ballot should take. However, the final decision on the form of ballot(s) is the Secretary's - see 7.1(1), 7.1(3) and A.3(4). + +# The minimum discussion period is counted from the time the last formal amendment was accepted, or since the whole resolution was proposed if no amendments have been proposed and accepted. + +2~a3 A.3. Voting procedure + +# Each resolution and its related amendments is voted on in a single ballot that includes an option for the original resolution, each amendment, and the default option (where applicable). + +# The default option must not have any supermajority requirements. Options which do not have an explicit supermajority requirement have a 1:1 majority requirement. + +# The votes are counted according to the rules in A.6. The default option is "Further Discussion", unless specified otherwise. + +# In cases of doubt the Project Secretary shall decide on matters of procedure. + +2~a4 A.4. Withdrawing resolutions or unaccepted amendments + +The proposer of a resolution or unaccepted amendment may withdraw it. In this case new proposers may come forward keep it alive, in which case the first person to do so becomes the new proposer and any others become sponsors if they aren't sponsors already. + +A sponsor of a resolution or amendment (unless it has been accepted) may withdraw. + +If the withdrawal of the proposer and/or sponsors means that a resolution has no proposer or not enough sponsors it will not be voted on unless this is rectified before the resolution expires. + +2~a5 A.5. Expiry + +If a proposed resolution has not been discussed, amended, voted on or otherwise dealt with for 4 weeks the secretary may issue a statement that the issue is being withdrawn. If none of the sponsors of any of the proposals object within a week, the issue is withdrawn. + +The secretary may also include suggestions on how to proceed, if appropriate. + +2~a6 A.6. Vote Counting + +# Each voter's ballot ranks the options being voted on. Not all options need be ranked. Ranked options are considered preferred to all unranked options. Voters may rank options equally. Unranked options are considered to be ranked equally with one another. Details of how ballots may be filled out will be included in the Call For Votes. + +# If the ballot has a quorum requirement R any options other than the default option which do not receive at least R votes ranking that option above the default option are dropped from consideration. + +# Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration. + +_# Given two options A and B, V(A,B) is the number of voters who prefer option A over option B. + +_# An option A defeats the default option D by a majority ratio N, if V(A,D) is strictly greater than N * V(D,A). + +_# If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1. + +# From the list of undropped options, we generate a list of pairwise defeats. + +_# An option A defeats an option B, if V(A,B) is strictly greater than V(B,A). + +# From the list of [undropped] pairwise defeats, we generate a set of transitive defeats. + +_# An option A transitively defeats an option C if A defeats C or if there is some other option B where A defeats B AND B transitively defeats C. + +# We construct the Schwartz set from the set of transitive defeats. + +_# An option A is in the Schwartz set if for all options B, either A transitively defeats B, or B does not transitively defeat A. + +# If there are defeats between options in the Schwartz set, we drop the weakest such defeats from the list of pairwise defeats, and return to step 5. + +_# A defeat (A,X) is weaker than a defeat (B,Y) if V(A,X) is less than V(B,Y). Also, (A,X) is weaker than (B,Y) if V(A,X) is equal to V(B,Y) and V(X,A) is greater than V(Y,B). + +_# A weakest defeat is a defeat that has no other defeat weaker than it. There may be more than one such defeat. + +# If there are no defeats within the Schwartz set, then the winner is chosen from the options in the Schwartz set. If there is only one such option, it is the winner. If there are multiple options, the elector with the casting vote chooses which of those options wins. + +/{Note}/: Options which the voters rank above the default option are options they find acceptable. Options ranked below the default options are options they find unacceptable. + +/{When the Standard Resolution Procedure is to be used, the text which refers to it must specify what is sufficient to have a draft resolution proposed and/or sponsored, what the minimum discussion period is, and what the voting period is. It must also specify any supermajority and/or the quorum (and default option) to be used.}/ + +1~b B. Use of language and typography + +The present indicative ('is', for example) means that the statement is a rule in this constitution. 'May' or 'can' indicates that the person or body has discretion. 'Should' means that it would be considered a good thing if the sentence were obeyed, but it is not binding. Text marked as a citation, such as this, is rationale and does not form part of the constitution. It may be used only to aid interpretation in cases of doubt. + +%% SiSU markup sample Notes: +% SiSU http://www.jus.uio.no/sisu +% SiSU markup for 0.16 and later: +% 0.20.4 header 0~links +% 0.22 may drop image dimensions (rmagick) +% 0.23 utf-8 ß +% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title) +% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6 +% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html +% markup in this document is 0.38, (rad) experimental diff --git a/debian/data/doc/sisu/v1/markup-samples/samples/debian_constitution_v1.2~da.sst b/debian/data/doc/sisu/v1/markup-samples/samples/debian_constitution_v1.2~da.sst new file mode 100644 index 00000000..158d0b83 --- /dev/null +++ b/debian/data/doc/sisu/v1/markup-samples/samples/debian_constitution_v1.2~da.sst @@ -0,0 +1,504 @@ +% SiSU 1.0 + +@title: Debians vedtægter + +@subtitle: Debian-projektets vedtægter (v1.2) [This Document has been Superseded by v1.3] + +@creator: Debian Project + +@type: information + +@subject: debian policy + +@date.created: 1998-12-03 + +@date.issued: 1998-12-03 + +@date.valid: 2003-10-29 + +@date.available: 2003-10-29 + +@date.modified: 2003-10-29 + +@date: 2003-10-29 + +@language.document: Danish + +@language.original: English + +@level: new=C; num_top=1 + +@skin: skin_debian + +@bold: Debian; DPL + +% @italics: + +@rights: http://www.debian.org/license.da.html Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/ <br>Dette materiale må kun distribueres i henhold til vilkårene beskrevet i Open Publication License, udkast (draft) v1.0 eller senere (du kan læse vores lokale kopi http://www.debian.org/opl, den seneste version er normalt tilgængelig på http://www.opencontent.org/openpub/ ).<br>"Debian" og Debians logo http://www.debian.org/logos/ er varemærker tilhørende Software in the Public Interest, Inc.<br>Dette er en oversættelse af det originale engelsksprogede dokument http://www.debian.org/license.en.html. + +@links: {Authoritative Source Document}http://www.debian.org/devel/constitution +{SiSU version using default markup}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html +{SiSU version markup adjusted to correspond to original document}http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html +{Debian Social Contract @ SiSU}http://www.jus.uio.no/sisu/debian_social_contract_v1.1/sisu_manifest.html +{About Debian}http://www.debian.org/intro/about +{News}http://www.debian.org/News/ +{Getting Debian}http://www.debian.org/distrib/ +{Support}http://www.debian.org/support +{Developer's Corner}http://www.debian.org/devel/ +{Sitemap}http://www.debian.org/sitemap +{Search}http://search.debian.org/ + +@prefix: This is taken from the authoritative source at http://www.debian.org/devel/constitution and is marked up and generated to check SiSU default settings, please note that the sub-numbering in using letters is not identical to the original.<br>Version 1.2 ratified on October 29th, 2003. Supersedes Version 1.1 http://www.debian.org/devel/constitution.1.1 ratified on June 21st, 2003, which itself supersedes Version 1.0 http://www.debian.org/devel/constitution.1.0 ratified on December 2nd, 1998.<br>Two different SiSU marked up versions are provided http://www.jus.uio.no/sisu/debian_constitution_v1.2/sisu_manifest.html uses simpler markup, the default numbering mode; http://www.jus.uio.no/sisu/debian_constitution_v1.2.adjusted/sisu_manifest.html uses more complicated numbering in the markup and is more true to the original + +@rcs: $Id: debian_constitution_v1.2~dk.s3,v 1.7 2006/02/28 12:11:55 ralph Exp $ + +:A~ Debians vedtægter + +:B~ Debian-projektets vedtægter (v1.2) [This Document has been Superseded by v1.3] + +1~pre [Prefix]-# + +Version 1.2 blev godkendt den 29. oktober 2003. Erstatter version 1.1 som blev godkendt den 21. juni 2003, der erstattede version 1.0 som blev godkendt den 2. december 1998. + +1~1 §1. Introduktion + +Debian-projektet er en sammenslutning af personer, som har det fælles mål at udvikle et frit tilgængeligt styresystem. + +Dette dokument beskriver organisationsstrukturen for formelle beslutninger i projektet. Det beskriver ikke projektets mål eller hvordan vi opfylder disse, og indeholder ingen retningslinier, bortset fra de retningslinier som direkte vedrører beslutningsprosessen. + +1~2 §2. Beslutningsdygtige organer og -personer + +Enhver beslutning i projektet er omfattet af en eller flere af følgende: + +# Udviklerne, via en fælles resolution eller et valg; + +# Projektlederen; + +# Den tekniske komité og/eller dennes formand; + +# Den individuelle udvikler som arbejder med en bestemt opgave; + +# Delegater udnævnt af projektlederen til at varetage særlige opgaver; + +# Projektsekretæren. + +Resten af dette dokument vil primært beskrive disse organers fuldmagter, deres sammensætning og udnævnelse, og procedurer for vedtagelser. En persons eller et organs fuldmagt kan i visse tilfælde blive genstand for gennemsyn af andre; i så fald vil det fremgå af afsnittet om det organ, der står for dette. I listen ovenfor er hver person eller hvert organ stort set anført før de personer eller organer de kan (hjælpe til med at) udnævne, og hvis beslutninger de kan ophæve - men ikke alle, der er anført tidligere, kan ophæve beslutninger fortaget af alle som er anført senere. + +2~2.1 §2.1. Generelle regler + +# Intet i disse vedtægter forpligter nogen til at arbejde for projeket. En person, der ikke vil udføre en opgave, som er blevet uddelegeret eller pålagt vedkommende, behøver at gøre det. Derimod kan man ikke aktivt modarbejde regler eller beslutninger, som er foretaget korrekt i henhold til reglerne. + +# En person kan bestride flere hverv, bortset fra at projektlederen, projektsekretæren og formanden for den tekniske komité skal være forskellige personer, og lederen kan ikke udnæve sig selv, som sin egen delegat. + +# En person kan til enhver tid forlade projektet eller fratræde et særskilt hverv vedkommende har, ved offentligt at erklære dette. + +1~3 §3. Individuelle udviklere + +2~3.1 §3.1. Fuldmagt + +En individuel udvikler kan + +# tage tekniske og ikke-tekniske beslutninger med hensyn til sit eget arbejde; + +# foreslå og støtte udkast til generelle resolutioner; + +# foreslå sig selv som kandidat til projektleder i valg; + +# stemme på generelle resolutioner og i ledervalg. + +2~3.2 §3.2. Sammensætning og udnævnelse + +# Udviklere er frivillige som er enige om at fremme projektets mål for så vidt som de deltager i det, og som vedligeholder pakke(r) for projektet eller gør andet arbejde, som projeketlederens delegater anser for værdifuldt. + +# Projektlederens delegater kan vælge ikke at optage nye udviklere, eller at ekskludere nuværende udviklere. Hvis udviklerne mener at delegaterne misbruger deres autoritet, kan de selvfølgelig ophæve en beslutning via en generel resolution - se §4.1(3) og §4.2. + +2~3.3 §3.3. Fremgangsmåder + +Udviklerne kan foretage disse beslutninger efter eget skøn. + +1~4 §4. Udviklerne via generel resolution eller et valg + +2~4.1 §4.1. Fuldmagt + +Udviklerne kan sammen: + +# Udnævne eller afsætte projektlederen. + +# Ændre disse vedtægter med et 3:1-flertal. + +# Ophæve enhver beslutning taget af projektlederen eller en delegat. + +# Ophæve enhver beslutning taget af den tekniske komité, såfremt de er enige med et 2:1-flertal. + +# Udgive, erstatte og tilbagetrække ikke-tekniske retningslinier og erklæringer. + +Dette inkluderer dokumenter som forklarer projektmål, dets forhold til andre organer indenfor fri software, samt ikke-tekniske vejledninger som de fri software-licensbetingelser, som Debians programmel skal leve op til. + +Det kan også være stillingtagen til aktuelle emner. + +_# Et grundlæggende dokument er et dokument eller en bekendtgørelse, der betragtes som kritisk for projekts arbejde og formål. + +_# De grundlæggende dokumenter er det arbejde som er udmundet i Debian sociale kontrake og Debians retningslinier for fri software. + +_# Et grundlæggende dokument kræver et 3:1-flertal for dets erstatning. Nye grundlæggende dokumenter udgives og eksisterende dokumenter trækkes tilbage ved at føje til listen over grundlæggende dokumenter i disse vedtægter. + +# Træffe beslutninger sammen med projektlederen og SPI om forvaltede ejendele til formål der har relation til Debian. (Se §9.1). + +2~4.1 §4.2. Fremgangsmåde + +# Udviklerne følger de generelle resolutionsprocedurer beskrevet nedenfor. En resolution eller ændring betragtes som introduceret, hvis den er foreslået af en hvilken som helst udvikler og mindst K andre udviklere støtter den, eller hvis den er foreslået af projektlederen eller den tekniske komité. + +# Udsættelse af en resolution foretaget af projektlederen eller dennes delegater: + +_# Hvis projektlederen, dennes delegater eller den tekniske komité har truffet en beslutning, kan udviklerne ophæve denne ved at vedtage en resolution derom, se §4.1(3). + +_# Hvis en sådan resolution støttes af mindst 2K udviklere eller hvis den er foreslået af den tekniske komité, vil resolutionen omgående tilsidesætte beslutningen (såfremt resolutionen selv siger dette). + +_# Hvis den oprindelige beslutning var at ændre en diskussionsperiode eller en stemmeperiode, eller hvis resolutionens formål er at ophæve en beslutning foretaget af den tekniske komité, behøver kun K udviklere at støtte resolutionen, for omgående at kunne tilsidesætte beslutningen. + +_# Hvis beslutningen er tilsidesat, holdes omgående en afstemning for at afgøre om beslutningen skal opretholdes indtil en fuldstændig afstemning om beslutningen kan holdes, eller om udførslen af den oprindelige beslutning skal udsættes indtil da. Der findes ikke et beslutningsdygtigt antal stemmer i denne omgående, proceduriske afstemning. + +_# Hvis projektlederen (eller dennes delegater) trækker den oprindelige beslutning tilbage, bliver det uaktuelt at holde afstemningen og den vil ikke blive afholdt. + +# Stemmer indsamles af projektsekretæren. Stemmerne og afstemningsresultatet offentliggøres ikke i stemmeperioden; efter afstemningen opremser projektsekretæren alle de afgivne stemmer, Afstemningsperioden er to uger, men projektlederen kan tilføje eller fjerne op til en uge. + +# Minimumstiden for diskussion er to uger, men projektlederen kan tilføje eller fjerne op til en uge. Projektlederen har den afgørende stemme. Det beslutningsdygtige antals stemmer er 3Q. + +# Forslag, støtte, ændringer, stemmeopråb og andre formelle handlinger foregår via erklæringer på en offentlig tilgængelig elektronisk postliste udvalgt af projektlederens delegat(er); alle udviklere har skriveadgang til den. + +# Stemmer afgives via e-mail på en måde der bestemmes af sekretæren. Sekretæren bestemmer for hver afstemning hvorvidt vælgerne kan ændre deres stemmer. + +# Q er halvdelen af kvadratroden af antallet af udviklere. K er den mindste af Q og 5. Q og K behøver ikke at være heltal, og de afrundes ikke. + +1~5 §5. Projektlederen + +2~5.1 §5.1. Fuldmagt + +Projektlederen kan: + +# Udnævne delegater eller uddelegere beslutninger til den tekniske komité. + +Lederen kan beskrive en opgave med løbende ansvar eller en særskilt beslutning. I begge tilfælde overføres denne til en anden udvikler eller til den tekniske komité. + +Efter en særskilt beslutning er blevet uddelegeret og afgjort, kan projektlederen ikke trække uddelegeringen tilbage. derimod kan en løbende uddelegerning til en bestemt opgave trækkes tilbage. + +# Give hjemmel til andre udviklere. + +Projektlederen kan udgive støtteerklæringer til andres synspunkter eller andre projektmedlemmer, uden at være blevet bedt om det. Disse støtteerklæringer er gyldige, hvis, og kun hvis, lederen ville have haft fuldmagt til at træffe den foreliggende beslutning. + +# Foretage beslutninger som kræver omgående handling. + +Dette gælder ikke beslutninger som gradvist er blevet påtrængende på grund af manglende, relevant handling, med mindre der er en fastsat frist. + +# Foretage beslutninger som ingen andre har ansvaret for. + +# Fremstille udkast til generelle resolutioner og ændringsforslag. + +# Sammen med den tekniske komité udpege nye medlemmer til komitéen. (Se §6.2.) + +# Afgive en afgørende stemme i udviklernes afstemninger. + +Projektlederen har også almindelig stemmeret i sådanne afstemninger. + +# Ændre diskussionsperioden for udviklernes afstemninger (som beskrevet ovenfor). + +# Lede diskussioner blandt udviklerne. + +Projektlederen bør prøve at deltage i diskussioner blandt udviklerne på en hjælpsom måde, som søger at bringe diskussionen på rette kurs mod sagens kerne. Projektlederen bør ikke bruge lederpositionen til at fremme sine egne personlige synspunkter. + +# Tage beslutninger sammen med SPI, der vedrører ejendele som administreres til formål der vedrører Debian. (Se §9.1.) + +2~5.2 §5.2. Udnævnelse + +# Projektlederen vælges af udviklerne. + +# Valget begynder ni uger før lederpositionen bliver ledig eller (hvis det ikke allerede er for sent) omgående. + +# I de følgende tre uger kan enhver udvikler nominere sig selv som projektlederkandidat. + +# I de efterfølgende tre uger kan der ikke nomineres flere kandidater; kandiaterne bør anvende dette tidsrum til deres valgkamp (for at gøre opmærksom på sig selv og sine synspunkter). Hvis der ikke er nogen kandidater efter nomineringsperioden er slut, bliver perioden udvidet med yderligere tre uger, om nødvendigt gentagne gange. + +# De næste tre uger er valgperioden, hvori udviklerene kan stemme. Afstemningen i ledervalg er hemmelig, selv efter afstemningen er afsluttet. + +# Valget vil være mellem de kandidater, der har nomineret sig selv og som ikke har trukket sig tilbage, samt Ingen af de nævnte ("None of the Above"). Hvis Ingen af de nævnte vinder valget, bliver denne procedure gentaget, om nødvendigt mange gange. + +# Beslutningen træffes ved hjælp af den metode, som er beskrevet i afsnit §A.6 i de generelle resolutionsprocedurer. Det beslutningsdygtige antal er det samme, som ved en generel resolution (§4.2), og standardvalget er Ingen af de nævnte. + +# Projektlederen vælges for et år ad gangen. + +2~5.3 §5.3. Fremgangsmåde + +Projektlederen bør prøve at træffe beslutninger som er i tråd med konsensus blandt udviklerne. + +Hvor det er praktisk bør projektlederen på en uformel måde bede om udviklernes synspunkter. + +Projektlederen bør undgå at lægge for megen vægt på sine egne synspunkter, når der træffes beslutninger i vedkommendes egenskab af leder. + +1~6 §6. Teknisk komité + +2~6.1 §6.1. Fuldmagt + +Den tekniske komité kan: + +# Træffe beslutninger om tekniske retningslinier. + +Deriblandt også indholdet af de tekniske retningslinier, udviklernes håndbogsmateriale, pakkeeksempler og hvordan ikke-eksperimentelle pakkeopbygningsværktøjer skal fungere. (I hvert tilfælde træffer den almindelige pakkevedligeholder af programmellet eller dokumentationen, de første beslutninger; se §6.3(5).) + +# Afgøre tekniske spørgsmål hvor udviklernes ansvarsområder overlapper. + +I tilfælde hvor udviklere skal implementere kompatible tekniske retningslinier eller holdninger (for eksempel hvis de ikke er enige om prioriteringerne ved uforenlige pakker, eller om ejerskab af et kommandonavn, eller om hvilken pakke der er ansvarlig for en fejl som begge pakkevedligeholdere er enige om er en fejl, eller om hvem der bør være vedligeholder af en pakke), kan den tekniske komité afgøre sagen. + +# Træffe en beslutning når den bliver bedt om at gøre dette. + +Enhver person og ethvert organ kan uddelegere en af sine egne beslutninger til den tekniske komité eller bede om råd fra den. + +# Tilsidesætte en udviklers beslutning (kræver et 3:1-flertal) + +Den tekniske komité kan bede en udvikler om at benytte en bestemt fremgangsmåde, selvom udvikleren ikke ønsker det; dette kræver et 3:1-flertal. For eksempel kan komitéen komme frem til at en klage fremsat i en fejlrapport er gyldig og at indsenderens foreslåede løsning bør iværksættes. + +# Give råd. + +Den tekniske komité kan give formelle erklæringer om sit syn på enhvert emne. Individuelle medlemmer kan selvfølgelig give uformelle erklæringer om deres synspunkter og om komitéens sandsynlige synspunkter. + +# Sammen med projektlederen udnævne nye medlemmer til sig selv eller fjerne nuværende medlemmer. (Se §6.2.) + +# Udnævne formanden for den tekniske komité. + +Komitéen vælger formand blandt sine medlemmer. Medlemmerne af komitéen nomineres automatisk; valget starter en uge før stillingen bliver ledig (eller omgående, hvis det allerede er for sent). Medlemmerne kan stemme via offentlig tilkendegivelse for hvilket som helst komitémedlem, også sig selv. Der er intet standardvalg. Valget afsluttes når alle medlemmerne har stemt eller stemmeperioden er afsluttet. Resultatet afgøres ved hjælp af den metode, som er angivet i §A.6 i de generelle resolutionsprocedurer. + +# Formanden kan vikariere for lederen, sammen med sekretæren + +Som beskrevet i §7.1(2), kan formanden for den tekniske komité og projektsekretæren i fællesskab vikariere for lederen, hvis der ikke er en leder. + +2~6.2 §6.2. Sammensætning + +# Den tekniske komité består af op til otte udviklere og bør normalt have mindst fire medlemmer. + +# Hvis det er mindre end otte medlemmer, kan den tekniske komité anbefale ny(e) medlem(mer) til projektlederen, som (på egen hånd) kan vælge at udnævne dem eller ej. + +# Hvis der er fem eller færre medlemmer, kan den tekniske komité udnævne ny(e) medlem(mer) indtil antallet af medlemmer når seks. + +# Når der har været fem eller færre medlemmer i mindst en uge, kan projektlederen udnævne nye medlem(mer) indtil antallet af medlemmer når seks, med mindst en uges mellemrum for hver udnævnelse. + +# Hvis den tekniske komité og projektlederen er enige kan de fjerne eller erstatte et nuværende medlem af den tekniske komité. + +2~6.3 §6.3. Fremgangsmåde + +# Den tekniske komité anvender den generelle resolutionsprocedure. + +Et udkast til en resolution eller ændring kan framsættes af ethvert medlem af den tekniske komité. Det er ingen minimumstid for diskussion; valgperioden varer i op til en uge eller indtil der ikke længere kan være nogen tvivl om resultatet. Medlemmerne kan ændre deres stemmer. Det beslutningsdygtige antal er to. + +# Detaljerede afstemningoplysninger + +Formanden har den afgørende stemme. Når den tekniske komité stemmer for at afgøre, om de skal tilsidesætte en afgørelse taget af en udvikler, der også er et medlem af komitéen, kan dette medlem ikke stemme (med mindre det er formanden, som i dette tilfælde kun kan benytte sin afgørende stemmeret). + +# Offentlig diskussion og afgørelser + +Diskussioner, udkast til resolutioner og ændringer og komitemedlemmernes stemmer offentliggøres på den tekniske komités offentlige diskussionsliste. Der er ikke en særskilt sekretær for komitéen. + +# Fortrolighed ved udnævnelser + +Den tekniske komité kan holde fortrolige diskussioner via privat e-mail eller en privat postliste, eller på andre måder diskutere udnævnelser til komitéen. Derimod skal stemmerne ved udnævnelser offentliggøres. + +# Ikke et detaljeret udviklingsarbejde + +Den tekniske komité giver sig ikke i kast med fremstilling af nye forslag og retningslinier. Sådant udviklingsarbejde bør foretages privat af personer eller grupper, og diskuteres i almindelige tekniske og udviklingsfora. + +Den tekniske komité begrænser sig selv til at vælge blandt, eller vælge et kompromis mellem, løsninger og afgørelser, der er blevet foreslået og er blevet drøftet tilpas meget andre steder. + +Medlemmer af den tekniske komité kan selvfølgelig deltage på egne vegne i alle aspekter af udviklings- og retningsliniearbejde. + +# Den teknisk komité træffer kun afgørelser som en sidste udvej + +Den tekniske komité træffer ikke en teknisk afgørelse før der uden held har været gjort forsøg på at løse problemet ved konsensus, med mindre den er blevet bedt om at træffe en afgørelse af personen eller organet, der normalt ville have haft ansvar for at gøre dette. + +1~7 §7. Projektsekretæren + +2~7.1 §7.1. Fuldmagt + +Sekretæren: + +# Indsamler stemmer fra udviklerne, finder ud af hvor mange udviklere der er og hvem de er, når dette kræves af vedtægterne. + +# Kan vikariere for lederen, i fællesskab med formanden for den tekniske komité. + +Hvis der ikke er en projektleder, kan formanden for den tekniske komité og projektsekretæren træffe afgørelser ved enighed, hvis de mener at det er vigtigt at gøre dette. + +# Dømmer i stridigheder om tolkning af vedtægterne. + +# Kan uddelegere dele af eller hele sin fuldmagt til andre, eller til enhver tid trække en sådan uddelegering tilbage. + +2~7.2 §7.2. Udnævnelse + +Projektsekretæren udnævnes af projektlederen og den forrige projektsekretær. + +Hvis projektlederen og den forrige projektsekretær ikke kan blive enige om en ny udnævnelse, skal de bede SPI's bestyrelse (se §9.1) om at udnævne en ny sekretær. + +Hvis der ikke er en projektsekretær eller den forrige sekretær ikke kan træffes og ikke har uddelegeret sin fuldmagt til en sådan beslutning, kan beslutningen træffes eller uddelegeres af formanden for den tekniske komité, som fungerende sekretær. + +Projektsekretæren er valgt for et år ad gangen, hvorefter en ny (gen)udnævnelse er nødvendig. + +2~7.3 §7.3. Fremgangsmåde + +Projektsekretæren bør træffe afgørelser som er retfærdige og rimelige, og helst i overensstemmelse med konsensus blandt udviklerne. + +Når projektsekretæren og formanden for den tekniske komité i fællesskab vikarierer for en projektleder som ikke kan træffes, bør de kun træffe beslutninger som er helt nødvendige og kun når det er i overensstemmelse med konsensus blandt udviklerne. + +1~8 §8. Projektlederens delegater + +2~8.1 §8.1. Fuldmagt + +Projektlederens delegater: + +# har fået uddelegeret en fuldmagt fra projektlederen; + +# kan træffe visse afgørelser som lederen ikke kan tage på egen hånd, deriblandt optagelse eller afvisning af udviklere, eller udnævne folk der ikke håndterer pakker, som udviklere. Dette er for at undgå en magtkoncentration hos projektlederen, særligt med hensyn til udviklermedlemskab. + +2~8.2 §8.2. Udnævnelse + +Delegaterne udnævnes af projektlederen, og lederen kan udskifte dem, som han finder det passende. Projektlederen kan ikke gøre udnævnelse betinget af at delegaten træffer bestemte afgørelser, lederen kan heller ikke ophævne en beslutning truffet af en delegat. + +2~8.3 §8.3. Fremgangsmåde + +Delegater kan til enhver tid træffe afgørelser, men bør prøve at opnå gode tekniske vilkår og/eller følge konsensus. + +1~9 §9. Software in the Public Interest ("Software i offentlighedens interesse") + +SPI og Debian er adskilte organisationer, der har nogle fælles mål. Debian er taknemlig for det juridiske støtteapparat, som SPI tilbyder. Debians udviklere er pt. medlemmer af SPI i kraft af deres hverv som udviklere. + +2~9.1 §9.1. Fuldmagt + +# SPI har ingen fuldmagt hvad angår Debians tekniske eller ikke-tekniske beslutninger, bortset fra at ingen beslutninger foretaget af Debian som vedrører ejendele der administreres af SPI, kan kræve at SPI handler udenfor sin juridiske fuldmagt, og Debians vedtægter kan af og til gøre SPI til en afgørende myndighed, som en sidste udvej. + +# Debian har ingen bestemmende kontrol over SPI, bortset fra anvendelse af visse ejendele som beskrevet nedenfor, selvom Debians udviklere kan få fuldmagt indenfor SPI efter SPI's regler. + +# Debians udviklere er ikke repræsentanter for, eller ansat af, SPI, eller af personer med fuldmagt i Debian-projektet. En person der handler som udvikler, gør dette som et individ på egne vegne. + +2~9.2 §9.2. Administration af ejendele til formål som vedrører Debian + +Da Debian ikke har fuldmagt til at forvalte penge eller ejendele, skal donationer til Debian-projektet gives til SPI, som håndterer den slags. + +SPI har påtaget sig følgende: + +# SPI vil forvalte penge, varemærker, andre konkrete ejendele og forretninger til formål som vedrører Debian. + +# Sådanne ejendele vil der blive holdt særskilt regnskab for og blive indsat i en fond med det formål, udvalgt af Debian og SPI i henhold til denne paragraf. + +# SPI vil ikke afhænde eller anvende ejendele, de administrerer for Debian, uden samtykke med Debian, som kan gives af projektlederen eller via en generel resolution blandt udviklerne. + +# SPI vil overveje anvendelse og/eller afhændelse af ejendele de administrerer for Debian, når de bliver bedt om det af projektlederen. + +# SPI vil anvende eller afhænde ejendele som administreres for Debian når de bliver bedt om at gøre dette, via en generel resolution blandt udviklerne, såfremt dette er foreneligt med SPI's juridiske fuldmagt. + +# SPI vil via elektronisk post til en af Debian-projektets postlister, gør opmærksom på når ejendele, der administreres for Debian, anvendes eller afhændes. + +1~a A. Generel resolutionsprocedure + +Disse regler gælder fælles beslutninger truffet af komitéer og ved afstemninger, som beskrevet ovenfor. + +2~a1 A.1. Forslag + +Den formelle procedure begynder når et udkast til en beslutning er foreslået og støttet, som krævet. + +2~a1a A.1. Diskussion og ændring + +# Efter forslaget er fremsat, kan resolutionen diskuteres. Ændringsforslag kan gøres formelle ved at fremsætte dem og skaffe støtter jævnfør kravene for nye resolutioner, eller direkte af forslagsstilleren af det oprindelige forslag. + +# Et formelt ændringsforslag kan accepteres af resolutionens forslagsstiller, hvorved det formelle resolutionsudkast omgående ændres. + +# Hvis et formelt ændringsforslag ikke accepteres, eller en af støtterne til resolutionen ikke er enig med forslagsstillerens accept af et formelt ændringsforslag, holdes en særskilt afstemning om dette. + +# Hvis andre ikke kan lide et ændringsforslag, som er accepteret af den oprindelige forslagsstiller, kan de foreslå en anden ændring for at fjerne den tidligere ændring (igen skal de leve op til kravene om forslagsstiller og støtte(r).) + +# Forslagsstilleren af en resolution kan foreslå revideringer af formuleringen af ændringensforslaget; disse træder i kraft hvis forslagsstilleren af ændringsforslaget er enig og ingen af støtterne protesterer. I så fald stemmes der om det reviderede ændringsforslag i stedet for det oprindelige. + +# Forslagsstilleren af en resolution kan foretage ændringer for at rette mindre fejl (for eksempel stavefejl eller selvmodsigelser) eller ændringer som ikke forandrer meningen, såfremt ingen protesterer indenfor 24 timer. I disse tilfælde starter minimumsdiskussionsperioden ikke igen. + +2~a2 A.2. Afstemning + +# Forslagsstilleren eller en støtte til en resolution eller et ændringsforslag kan bede om afstemning efter at minimumstiden for diskussion (hvis en sådan findes) er gået. + +# Foreslagsstilleren eller en støtte til en resolution kan bede om en afstemning vedrørende resolutionen eller alle beslægtede ændringsforslag. + +# Personen, der beder om en afstemning, fremsætter hvad vedkommende mener resolutionens og alle relevante ændringsforslags ordlyd skal være, og dermed hvilken udformning afstemningen skal have. Dog er det projektsekretæren som træffer den endelige beslutning - se §§ 7.1(1), 7.1(3), og A.3(4). + +# Den minimale diskussionsperiode regnes fra det tidspunkt, det sidste formelle ændringsforslag blev accepteret eller fra det tidspunkt hele resolutionen blev fremsat, hvis ingen ændringer er blevet foreslået og accepteret. + +2~a3 A.3. Afstemningsprocedure + +# Der stemmes på hver resolution og dennes beslægtede ændringsforslag i en enkelt afstemning, der indeholder en valgmulighed som er den originale resolution, hvert ændringsforslag, samt et standardvalg (hvor det er muligt). + +# Standardvalget må ikke have krav om et absolut flertal. Valgmuligheder som ikke eksplicit har krav om absolut flertal, har et 1:1-krav. + +# Stemmerne tælles jf. reglerne i A.6. Standardvalget er "Yderligere diskussion" ("Further Discussion"), med mindre andet er angivet. + +# I tvivlstilfælde skal projektsekretæren afgøre procedurespørgsmål. + +2~a4 A.4. Tilbagetrukne resolutioner og ikke-accepterede ændringsforslag + +Foreslagsstilleren af en resolution eller et ændringsforslag som ikke er accepteret, kan trække disse tilbage. I så fald kan andre foreslagsstillere overtage og holde resolutionen eller ændringsforslaget i live, dermed bliver den første person der gør dette, den nye foreslagsstiller og de andre bliver støtter, hvis de ikke allerede er det. + +En støtte til en resolution eller en ændring kan trække sig tilbage (med mindre resolutionen allerede er blevet accepteret). + +Hvis foreslagsstillers og/eller støttes tilbagetrækning betyder at resolutionen ikke har en foreslagsstiller eller der ikke er støtter nok, holdes der ikke en afstemning, med mindre dette udredes før resolutionen udløber. + +2~a5 A.5. Udløb + +Hvis en foreslået resolution ikke er blevet diskuteret, ændret, stemt på eller på anden måde taget hånd om i fire uger, kan sekretæren udsende en besked om, at den betragtes som tilbagetrukket. Hvis ingen af foreslagets støtter har indvendiger, trækkes foreslaget tilbage. + +Sekretæren kan også vedlægge forslag til hvordan man fortsætter, hvis det er relevat. + +2~a6 A.6. Stemmeoptælling + +# Hver vælgers stemme prioriterer valgmulighederne. Man behøver ikke at prioritere alle valgmulighederne. Prioriterede valgmuligheder betragtes som foretrukne fremfor valgmuligheder, der ikke er prioriteret. Vælgere kan give valgmuligheder samme prioritet. Valgmuligheder, der ikke er prioriteret, betragtes som ligestillede med hinanden. Nærmere oplysninger om hvordan stemmesedlerne skal udfyldes, vil være vedlagt valgindkaldelsen. + +# Hvis det beslutningsdygtige antal er R, vil enhver valgmulighed som ikke er standardvalget og som ikke modtager mindst R stemmer, der prioriterer den mulighed højere end standardvalget, vil ikke blivetaget i betragtning. + +# Alle (ikke-standard-) valgmuligheder, der ikke overgår standardvalgmuligheden med dens krævede flertalsgrad, tages ikke i betragtning. + +_# Med de to valgmuligheder A og B, er V(A,B) antallet af vælgere der foretrækker mulighed A fremfor mulighed B. + +_# Valgmulighed A overgår standardvalgmulighed D med flertalsgraden N, hvis V(A,D) er større end N * V(D,A). + +_# Hvis et absolut flertal på S:1 er krævet af A, er dennes flertalsgrad S; ellers er flertalsgraden 1. + +# Ud fra listen over valgmuligheder der tages i betragtning, genereres en liste over parvise nederlag. + +_# Valgmulighed A overgår mulighed B, hvis V(A,B) er større end V(B,A). + +# Ud fra en liste over parvise nederlag (som tages i betragtning), genereres en liste over transitive nederlag. + +_# Valgmulighed A overgår transitivt mulighed C, hvis A overgår C eller hvis der er en en mulighed B, hvor A overgår B OG B transitivt overgår C. + +# Ud fra sættet af transitive nederlag konstruere et Schwartz-sæt. + +_# Valgmulighed A er i Schwartz-sættet hvis, for alle B-muligheders vedkommende, A transitivt overgår B, eller B ikke overgår A transitivt. + +# Hvis der er nederlag mellem valgmuligheder i Schwartz-sættet, ses der bort fra de svageste af sådanne nederlag i listen over parvise nederlag, og man springer tilbage til trin 5. + +_# Nederlaget (A,X) er svagere end nederlaget (B,Y), hvis V(A,X) er mindre end V(B,Y). Hvis (A,X) desuden er svagere end (B,Y), hvis V(A,X) er lig med V(B,Y) og V(X,A) er større end V(Y,B). + +_# Et svageste nederlag, er et nederlag hvortil der ikke er et svagere nederlag. Der kan være mere end et af sådanne nederlag. + +# Hvis der ikke nogen nederlag i Schwartz-sættet, tages vinderen fra valgmulighederne i Schwartz-sættet. Hvis der kun er en af disse valgmuligheder, er den vinderen. Hvis der er flere valgmuligheder, afgørerer vælgeren med den afgørende stemme, hvem af disse valgmuligheder, der er vinderen. + +Bemærk: Valgmuligheder, som vælgerne prioriterer over standardvalgmuligheden, er muligheder de betragter som acceptable. Valgmuligheder, der prioriteres under standardvalgmuligheder, er muligheder, der betragtes som uacceptable. + +Når den generelle resolutionsprocedure anvendes, skal teksten som henviser til denne, fastsætte hvad der er tilstrækkeligt for at få et udkast til en resolution foreslået og/eller støttet, hvad minimumstiden for diskussion er, og hvad afstemningsperioden er. Den skal også fastsætte det eventuelle kvalificerede flertal og beslutningsdygtige antal, som skal anvendes. + +1~b B. Brug af sprog og typografi + +Nutid ("er", for eksempel) betyder at udtrykket er en regel i disse vedtægter. "Kan" og "skal" indikerer at personen eller organet kan anvende skøn. "Bør" betyder at det vil anses som en god ting om hvis sætningen følges, men den er ikke bindende. Tekst markeret som et citat, som dette, er baggrundsmateriale og udgør ikke en del af vedtægterne. Den kan kun anvendes til at hjælpe med at tolke teksten i tvivlstilfælde. + +Bemærk: Dette er en oversættelse af det originale engelsksprogede dokument. Brug altid originalen i diskussioner om vedtægterne, da denne dansksprogede udgave er oversætterens fortolkning, som desuden kan indeholde fejl og misforståelser. + +%% SiSU markup sample Notes: +% SiSU http://www.jus.uio.no/sisu +% SiSU markup for 0.16 and later: +% 0.20.4 header 0~links +% 0.22 may drop image dimensions (rmagick) +% 0.23 utf-8 ß +% 0.38 or later, may use alternative notation for headers, e.g. @title: (instead of 0~title) +% 0.38 document structure alternative markup, experimental (rad) A,B,C,1,2,3 maps to 1,2,3,4,5,6 +% Output: http://www.jus.uio.no/sisu/autonomy_markup0/sisu_manifest.html +% markup in this document is 0.38, (rad) experimental diff --git a/debian/data/doc/sisu/v1/markup-samples/samples/debian_constitution_v1.2~de.sst b/debian/data/doc/sisu/v1/markup-samples/samples/debian_constitution_v1.2~de.sst new file mode 100644 index 00000000..26110a51 --- /dev/null +++ b/debian/data/doc/sisu/v1/markup-samples/samples/debian_constitution_v1.2~de.sst @@ -0,0 +1,506 @@ +% SiSU 1.0 + +@title: Debian-Verfassung + +@subtitle: Verfassung für das Debian-Projekt (v1.2) [This Document has been Superseded by v1.3] + +@creator: Debian Project + +@type: information + +@subject: debian policy + +@date.created: 1998-12-03 + +@date.issued: 1998-12-03 + +@date.valid: 2003-10-29 + +@date.available: 2003-10-29 + +@date.modified: 2003-10-29 + +@date: 2003-10-29 + +@language.document: German + +@language.original: English + +@level: new=C; num_top=1 + +@skin: skin_debian + +@bold: Debian; DPL + +% @italics: + +@rights: http://www.debian.org/license.de.html Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/ <br>Dieses Material darf nur unter den Bestimmungen, die in der Open Publication License, Draft v1.0 oder später (Sie können unsere lokale Kopie lesen http://www.debian.org/opl, die neuste Version ist normalerweise unter unter http://www.opencontent.org/openpub/ verfügbar) festgehalten sind, weitergegeben werden.<br>"Debian" und das Debian-Logo http://www.debian.org/logos/ sind Warenzeichen von Software in the Public Interest, Inc.<br>Dies ist die deutsche Übersetzung von "Debian's license" http://www.debian.org/license.en.html. In Zweifelsfällen ist das englische Original maßgeblich. + +% @rights: http://www.debian.org/license Copyright © 1997-2006 Software in the Public Interest, Inc., P.O. Box 501248, Indianapolis, IN 46250-6248, United States, http://www.spi-inc.org/ <br>This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, Draft v1.0 or later (you can read our local copy http://www.debian.org/opl, the latest version is usually available at http://www.opencontent.org/ ). <br>"Debian" and the Debian Logo are trademarks of Software in the Public Interest, Inc. |