diff options
| author | Thomas Lange <lange@debian.org> | 2023-10-06 12:45:37 +0200 |
|---|---|---|
| committer | Thomas Lange <lange@debian.org> | 2023-10-06 12:45:37 +0200 |
| commit | 9f5b551837a8d4c6a8c9346cf4c44755b863a813 (patch) | |
| tree | 0856db540a5d047169c7b6513e04d38306bff237 /greek/devel | |
| parent | 794834c196b3285bb39846e22bfab051860258ab (diff) | |
remove a lot of files which are not translations but only copies of the english version
Diffstat (limited to 'greek/devel')
78 files changed, 0 insertions, 14787 deletions
diff --git a/greek/devel/buildd/Makefile b/greek/devel/buildd/Makefile deleted file mode 100644 index c26323c0c92..00000000000 --- a/greek/devel/buildd/Makefile +++ /dev/null @@ -1 +0,0 @@ -include $(subst webwml/greek,webwml/english,$(CURDIR))/Makefile diff --git a/greek/devel/buildd/index.wml b/greek/devel/buildd/index.wml deleted file mode 100644 index 2bcfd527d3c..00000000000 --- a/greek/devel/buildd/index.wml +++ /dev/null @@ -1,168 +0,0 @@ -#use wml::debian::template title="Autobuilder network" -#use wml::debian::translation-check translation="63e5091d45458638e03a89dee1560f547b0cf0fc" maintainer="galaxico" - -<p>The autobuilder network is a Debian development that manages -package compilations for all the architectures <a -href="$(HOME)/ports/">Debian currently supports</a>. This -network is made up of several machines that use a specific software -package called <em>buildd</em> to pick up packages from the Debian -archive and rebuild them for the target architecture.</p> - -<h2>Why is the autobuilder network needed?</h2> - -<p>The Debian distribution supports <a href="$(HOME)/ports/">quite a -few architectures</a>, but the package maintainers usually only -compile binary versions for a single architecture they have access to -(usually i386 or amd64). The other builds are produced automatically, -ensuring that every package is only built once. Failures are tracked -in the autobuilder database.</p> - -<p> -As Debian/m68k (the first non-Intel port) started, developers for -it had to watch out for new versions of packages and recompile them -if they wanted to stay up-to-date with the Intel distribution. All -this was done manually: developers watched the upload mailing list for -new packages and took some of them for building. Coordination that no -package is built twice by different people was done by announcing on a -mailing list. It's obvious that this procedure is error-prone and -time-consuming. This was, however, the usual way for keeping non-i386 -distributions current for a long time. -</p> - -<p> -The build daemon system automates most of this process. It consists of -a set of scripts (written in Perl and Python) that have evolved over -time to help porters with various tasks. They have finally developed -into a system that is able to keep Debian distributions up-to-date nearly -automatically. The security updates are built on the same set of -machines to ensure their timely availability. -</p> - -<h2>How does buildd work?</h2> - -<p><em>Buildd</em> is the name usually given to the software used by the -autobuilder network, but it's really made of different parts:</p> - -<dl> - -<dt>wanna-build</dt> -<dd> -a tool that helps coordinate package (re)building through a database -that keeps a list of packages and their status. There is one central -database per architecture that stores package states, versions, and -some other information. It's fed with Sources and Packages files -retrieved from the various package archives Debian has (e.g. -ftp-master and security-master). -</dd> - -<dt><a href="https://packages.debian.org/buildd">buildd</a></dt> -<dd> -a daemon that periodically checks the database maintained by -<em>wanna-build</em> and calls <em>sbuild</em> to build the packages. -After the build log was acknowledged by the buildd administrator it -uploads the package to the appropriate archive. -</dd> - -<dt><a href="https://packages.debian.org/sbuild">sbuild</a></dt> -<dd> -is responsible for the actual compilation of packages in isolated chroots. -It ensured that all needed source dependencies are installed into the -chroot before building and then calls standard Debian tools to start -the build process. Build logs are submitted to the -<a href="https://buildd.debian.org">build log database</a>. -</dd> - -</dl> - -<p>All these parts <a href="operation">operate</a> -together in order to make the builder network work.</p> - -<h2>What does a Debian developer need to do?</h2> - -<p>Actually, an average Debian developer does not need to explicitly use -the buildd network. Whenever he uploads a package to the archive -(binary compiled to a given architecture) it will be added to the database -for all architectures (in state <em>Needs-Build</em>). -Build machines will query the build database for packages in this state, -and will routinely take packages from that list. The list -is prioritized by previous compilation state (either <em>out-of-date</em> -or <em>uncompiled</em>), priority, section and package name. Furthermore, -to prevent some packages from starving at the end of the queue, the priorities -are dynamically adjusted with increasing waiting time in the queue.</p> - -<p>If the build succeeds in all architectures, the maintainer will not -need to do anything. All those binary packages will be uploaded to the -corresponding archive. If the build does not succeed the package will -enter special states (<em>Build-Attempted</em> for build failures that -were not reviewed, <em>Failed</em> for reviewed and reported bugs in -the package or <em>Dep-Wait</em>, if they depend on specific build -dependencies which are not available). -The autobuilder administrators will review packages which fail to build -and will report back to the maintainer, usually, opening up a bug in the -Bug Tracking System.</p> - -<p>Sometimes a package takes a long time to build for a given architecture -and that holds the package from entering <a href="$(HOME)/devel/testing">\ -testing</a>. If a package holds up a transition build priorities are -usually adjusted upon request by the Release Team. Other requests will -not be accepted as the increased waiting time in the queue will lead to -a higher build priority automatically.</p> - -<p>You can check that status of the different buildds attempt -of the packages that belong to any given maintainer by checking the -<a href="https://buildd.debian.org/status/">buildd logs</a>. -These logs are also linked from the Packages' Maintainer Overview.</p> - -<p>For more information on the different states a package can be -please read <a href="wanna-build-states">wanna-build-states</a>.</p> - -<h2>Where can I find additional information?</h2> - -<p>Of course, both the documentation and the source code available for these -different tools are the best way to find out how the buildd network -works. Additionally, the -<a href="$(HOME)/doc/manuals/developers-reference/pkgs.html#porting">\ -Porting and being ported</a> section of the -<a href="$(HOME)/doc/manuals/developers-reference/">Debian Developers -Reference</a> provides complementary information on how does it work and -it also provides some information on -<a href="$(HOME)/doc/manuals/developers-reference/tools.html#tools-builders">\ -package builders</a> and -<a href="$(HOME)/doc/manuals/developers-reference/tools.html#tools-porting">\ -porting tools</a> which are involved in the process of both setting -up and maintaining the buildd network.</p> - -<p>There are some statistics available for the autobuilder network at -<a href="https://buildd.debian.org/stats/">the buildd stats page</a>.</p> - -<h2>How can I setup my own auto-builder node?</h2> - -<p>There are several reasons why a developer (or user) -might want to setup and run an autobuilder:</p> - -<ul> -<li>To help in developing a port to a given architecture (when autobuilders -are needed).</li> -<li>To assess the impact of a given compiler optimisation or patch -by recompiling a large subset of packages.</li> -<li>To run tools that analyse packages for known mistakes and need to -be run in compiled packages. This is even needed when doing source -code analysis, for example, as a work-around for packages -using <tt>dpatch</tt>.</li> -</ul> - -<p>You can read more information on how you can -<a href="https://wiki.debian.org/BuilddSetup">setup an autobuilder</a>.</p> - -<h2>Contacting the buildd admins</h2> - -<p>The admins responsible for buildd's for a particular arch can be reached -at <email arch@buildd.debian.org>, for example <email -i386@buildd.debian.org>.</p> - -<hrline /> -<p><small>This introduction to the autobuilder network was written -with bits and pieces provided by Roman Hodek, -Christian T. Steigies, Wouter Verhelst, Andreas Barth, -Francesco Paolo Lovergine, Javier Fernández-Sanguino and -Philipp Kern.</small></p> diff --git a/greek/devel/buildd/operation.wml b/greek/devel/buildd/operation.wml deleted file mode 100644 index c0d9555026c..00000000000 --- a/greek/devel/buildd/operation.wml +++ /dev/null @@ -1,77 +0,0 @@ -#use wml::debian::template title="Outline of operation of the autobuilder network" BARETITLE="true" -#use wml::debian::translation-check translation="4094875c3a7aafc988b5f218b0a629fab415552a" maintainer="galaxico" - -<P> -At the heart of the system is the <TT>wanna-build</TT> database, which -keeps track of package versions and states. <TT>quinn-diff</TT> -compares the package lists for the target architecture against the list -of source packages after every archive update and feeds a list of packages -that need re-compilation into the database where they enter state -<TT>Needs-Build</TT>. - -<P> -All the build daemons (there can be more than one) query the database -regularly for such packages and take some of them so that they go -into state <TT>Building</TT>. Of course, humans also can take -packages, e.g. in special cases where automatic compilation isn't -possible. Here we also see the second purpose of <TT>wanna-build</TT>: -It ensures that the same version of a package won't be built twice. - -<DIV class="center"><A name="autobuilder34"></A> -<IMG SRC="scheme.png" alt="Autobuilder scheme"> -<p><STRONG>Figure:</STRONG> -Package States and Transitions</p> -</DIV> - -<P> -If everything goes well, a finished package can be uploaded later, -which is another state <TT>Uploaded</TT>. After that it will -eventually be installed into the Debian archive so it appears in the -updated package list for the target architecture. This list will be -merged into the database, so the package will go to state -<TT>Installed</TT> and remains there until the next version of the source package. - -<P> -There are several other states; they include: <TT>Failed</TT> is for -packages that failed to build due to errors in the sources, and the -errors are expected to be fixed in a successor version (after -reporting the problem, of course). So a new version will directly -enter <TT>Needs-Build</TT>, but with a warning that something was -wrong with the previous version. Along with this state an error -description is stored. State <TT>Dep-Wait</TT> is used when a package -needs some other packages to be compiled but those aren't available -yet and must be built before. This state stores a list of required -packages and maybe versions, and if all of them are known to be -installed the state changes back to <TT>Needs-Build</TT>. - -<P> -As we have already seen, the build daemon takes packages from the -database for compiling them. Let's look a bit closer: If it has some -packages to build, it uses <TT>sbuild</TT> for the actual compilation -process, and for each build a log is mailed to the maintainer of the -daemon. He reviews the log and decides what to do with the package: -upload it, set it to <TT>Failed</TT> or <TT>Dep-Wait</TT> and retry it, -etc... If a positive acknowledgement (a signed <TT>.changes</TT> -file) is received, the daemon moves it to an upload directory, from where -all packages are uploaded by a cron job. - -<P> -Looking at the log files is the only human intervention in the whole -process if no errors happen. There are two good reasons for not -further automating this: First, sometimes builds end with an ``OK'' -result but the build nevertheless failed for reasons that are -invisible to the machine. And second, directly uploading would require -to automatically PGP-sign the resulting files with a key without -passphrase on the build machine. I considered this an unacceptable -security hole. - -<P> -The build script <TT>sbuild</TT> more or less just calls some standard -Debian tools to compile the sources. It also helps with some common -tasks and bookkeeping and with automatically installing the -build-dependencies as requested by the package being built. - -<hrline /> -<p><small>Content developed by Roman Hodek for the -6th International Linux-Kongress 1999; it was gently updated to reflect -the current reality a bit more by Philipp Kern in 2009</small></p> diff --git a/greek/devel/buildd/wanna-build-states.wml b/greek/devel/buildd/wanna-build-states.wml deleted file mode 100644 index 15079d0f8b2..00000000000 --- a/greek/devel/buildd/wanna-build-states.wml +++ /dev/null @@ -1,304 +0,0 @@ -#use wml::debian::template title="Wanna-build states: an explanation" BARETITLE="true" -#use wml::debian::translation-check translation="b8114b588961778dbd04974c1464a2f388a90c28" maintainer="galaxico" - - <p>This page tries to explain what every wanna-build state means - and what will happen to a package when it's in that state. Its - target audience are Debian package maintainers that try to - understand why their package has, or has not, been built for a - specific architecture. Also, an explanation of the different log - results is given.</p> - - <p>Finally, a flowchart version of the wanna-build states is - <a href="#graphlink">available</a>, but do note that it doesn't talk - about everything mentioned in this document.</p> - -<h2>The wanna-build states</h2> -<p>For every Debian-supported architecture, there's a wanna-build -database installed on buildd.debian.org, with all packages and their current -compilation state. There are 8 states: <em>needs-build</em>, -<em>building</em>, <em>uploaded</em>, <em>dep-wait</em>, -<em>BD-Uninstallable</em>, <em>failed</em>, <em>not-for-us</em>, and -<em>installed</em>.</p> - -<p>Their meaning is as follows:</p> - <dl> - <dt><a name="needs-build">needs-build</a></dt> - <dd>A package marked <em>needs-build</em> has seen an upload of - a new version by its maintainer, but for a different - architecture than the one this wanna-build database is for; as - such, it needs a rebuild. If the state is - <em>needs-build</em>, it has not been picked up by an - autobuilder yet, but it will be (once one is available at a - time the specific package is near the top of the list). People - commonly say <q>a package is queued for rebuild</q> when they are - talking about a package in the <em>needs-build</em> state.<br /> - It may be interesting to note that the <em>needs-build</em> - queue is not a FIFO queue; rather, the ordering used is based - on the following criteria: - <ol> - <li>Packages' previous compilation states; packages that - have been built previously are given priority over new - packages. - </li> - <li>priorities (packages with <em>required</em> priority are - built before packages with <em>extra</em> priority) - </li> - <li>The section a package is in. This ordering is based on what - packages are deemed more important; e.g., section <em>games</em> is - built after section <em>base</em>, and section <em>libs</em> is - built before <em>devel</em>. - </li> - <li>an asciibetical ordering on the package name.</li> - </ol> - Additionally, under certain conditions, it may happen that a buildd - will not take packages at the head of the queue; for instance, - when a buildd can't find the source of a given package, it will - put it back in the queue (where it will then again be put at its - previous position, i.e. the head of the queue), but it will - ignore the package for a few hours. Another example where this - might happen is when an architecture has multiple autobuilders; - in that case, the architecture's porters may choose to build - larger packages on their faster autobuilders, and leave the - smaller ones for the slower machines in the pool. A buildd can - theoretically also explicitly request a different section ordering, - but that is not usually done.<br /> - There could be other situations where the queue order seems to - be ignored; but note that they are all exceptions. - </dd> - <dt><a name="building">building</a></dt> - <dd>A package is marked <em>building</em> from the moment an - autobuilder picks it from the top of the wanna-build queue - until the moment the autobuilder admin replies to the log. As - packages are not picked one by one, this means a package can - be (and usually is) marked <em>building</em> before the build has - actually started; however, as buildd builds packages in its - local queue on a FIFO basis, it should not take too long - anymore. Also, note that the state of a package is - <strong>not</strong> modified once the build is complete; only - when the autobuilder admin comes around to replying to the - logs.</dd> - <dt><a name="uploaded">uploaded</a></dt> - <dd>When a build attempt was successful, a build log is sent to - the autobuilder admin and to buildd.debian.org. The - autobuilder maintainer will then sign the .changes file which - is embedded in the build log, and send it to the - autobuilder. In reaction, the autobuilder will upload the - package and set its state to <em>uploaded</em>. As such, a - package in this state can be found in the incoming queue - (somewhere).<br /> - An autobuilder will not touch a package anymore once it's - state is <em>uploaded</em>, at least not until the next upload - or until a porter manually modifies the state of a package. - </dd> - <dt><a name="dep-wait">dep-wait</a></dt> - <dd>When a package fails due to missing build-time dependencies, - the autobuilder maintainer will send a mail to the - autobuilder, instructing it to remove the package sources and - to mark the package as <em>dep-wait</em> on the missing - build-dependencies. A package in such a state will - automatically, without human intervention, be marked - needs-build once said dependencies are available.<br /> - Originally, a package had to see a build attempt before the - maintainer would manually place it in the <em>dep-wait</em> - state. However, in august 2005 some code was added to - wanna-build which will make a package move from the <em><a - href='#installed'>installed</a></em> state directly to the - <em>dep-wait</em> state, if that is appropriate.<br /> - There are two specific cases in which it may happen that a - package is marked dep-wait forever; these are when a typing - error happened by specifying the <em>dep-wait</em> dependencies - (so that the package is marked dep-wait on a package that does - not and will not ever exist) and when a build-time dependency is - declared on a package which is marked <em>not-for-us</em>, or - which is in the <em>packages-arch-specific</em> list.<br /> - As an example to the latter, consider three packages: a package - <tt>foo</tt>, which exists for <tt>i386</tt> only; a package - <tt>bar</tt>, which exists for <tt>m68k</tt> only (and which roughly - performs the same function); and a package <tt>baz</tt>, which can be - built with one of <tt>foo</tt> or <tt>bar</tt>. Should the maintainer - of the <tt>baz</tt> package forget to add <tt>bar</tt> to the - Build-Depends, and should he or she add it when it is noticed that - <tt>baz</tt> is <em>dep-wait</em>ing on a non-existing <tt>foo</tt> for - <tt>m68k</tt>, then the <em>dep-wait</em> state for <tt>m68k</tt> will - have to be manually lifted by the <tt>m68k</tt> porters. - </dd> - <dt><a name="bd-uninstallable">BD-Uninstallable</a></dt> - <dd>During debconf9, <a - href='https://lists.debian.org/debian-wb-team/2009/07/msg00089.html'>Joachim - Breitner had the idea</a> of using edos-debcheck to verify - build-dependency installability of packages that would otherwise - go into state Needs-Build. At that point, wanna-build already - had the ability to check the immediate availability of - build-dependencies; but if a package couldn't be installed - because it build-depends on a which depends on b which depends - on c (>=1.2.3) and c is still at version 1.2.2, this would - not be detected, and the build would fail early because of - unavailable build-dependencies. Figuring those out was a manual - process for the buildd admin, and, usually, a lengthy one at - that. With the BD-Uninstallable patch, this is no longer a - problem. When your package is in BD-Uninstallable, it means one - of the build-dependencies is not installable (either - immediately, or because part of its dependency tree is not - available). Unfortunately, the BD-Uninstallable patch does not - provide information about which package, exactly, is missing; - please use edos-debcheck to find out. This problem will, - however, solve itself once the missing dependencies are indeed - available, and at that point your package will automatically - move to Needs-Build again. - </dd> - <dt><a name="wanna-build-state-failed">failed</a></dt> - <dd>If a build attempt failed, and the autobuilder maintainer - decides it is really a failure that should not be retried, a - package is marked as <em>failed</em>. A package will not leave - this state until a porter decides it should do so, or until a - new version is available. However, when a new version of a - package is available which was marked as <em>failed</em> in - the previous version, the autobuilder will ask its admin - whether or not the package should be retried; this is so that - packages which will obviously fail again will not waste buildd - time. Although failing a package before trying a build is - hardly ever the right thing to do, the option is available to - the autobuilder admin.<br /> - Note that a package will <strong>never</strong> be marked - <em>failed</em> without human intervention. - </dd> - <dt><a name="not-for-us">not-for-us</a></dt> - <dd>Certain specific packages are architecture-specific; for - instance, <tt>lilo</tt>, an i386 boot loader, should not be - rebuilt on alpha, m68k, or s390. However, <em>wanna-build</em> - does not look at the control file of a package when creating its - database; only at the packages' name and section, the previous - build state, and its priority. As such, by the first upload of - an architecture-specific package which should not be built on - other architectures, a build attempt is tried none the less (but - fails even before the build-time dependencies are downloaded - and/or installed)<br /> - Since autobuilders should not waste time trying to build - packages that aren't required for their architecture, there's - need for a way to list packages for which even an attempt to - build isn't required. The first solution to this problem was - <em>not-for-us</em>; however, as that is difficult to - maintain, <em>not-for-us</em> is deprecated nowadays; - autobuilder maintainers should use - <em>packages-arch-specific</em> instead, which is a list of - packages specific to one or more architectures instead of a - wanna-build state.<br /> - A package in <em>not-for-us</em> or - <em>packages-arch-specific</em> will <strong>not</strong> - leave this state automatically; if your package specifically - excluded a given architecture in its control file previously, - but now includes more architectures, it must be - <strong>manually</strong> requeued.<br /> - If you ever find yourself in the position that you have to ask - for this to happen, you can do so by asking the relevant buildd - maintainer. They can be reached at $arch@buildd.debian.org. - </dd> - <dt><a name="installed">installed</a></dt> - <dd>As the name suggests, a package marked <em>installed</em> is - compiled for the architecture the wanna-build database is - for. Before Woody was released, a package's state changed from - <em>uploaded</em> to <em>installed</em> after the daily katie - runs. With the implementation of <a - href="https://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200206/msg00002.html">Accepted-autobuild</a>, - however, this is no longer true; nowadays, a package goes - from state <em>uploaded</em> to <em>installed</em> when it is - accepted into the archive. This means that a package is - usually marked <em>installed</em> after 15 minutes, on - average. - </dd> - </dl> - <p>In addition to these eight states, <em>wanna-build</em> also - knows two -removed states, which are really corner cases. These - two states are <em>dep-wait-removed</em> and - <em>failed-removed</em>. They relate to their respective <q>plain</q> - state as follows: when a package in state <em>failed</em> or - <em>dep-wait</em> doesn't appear in a new Packages file which is - fed to <em>wanna-build</em> – when it appears it has been - removed – the information about that package isn't thrown - away, as it could be that the package not appearing in the - Packages file is just a temporary glitch, or that the package is - temporarily removed for some reason (but that it will - reappear in the archive, given time). Instead, in such a case, a - package is moved to a <em>-removed</em> state, so that the - information on why it failed or what it's waiting for can be - retained. Should the package reappear in a following Packages file - which is fed to wanna-build, it will then be moved from - <em>failed-removed</em> back to <em>failed</em>, or from - <em>dep-wait-removed</em> back to <em>dep-wait</em> before further - processing.</p> - <p> - It is not possible to access the wanna-build database directly; - this database is installed on ftp-master.debian.org, which is a - restricted host, and only autobuilders have an SSH key which - allows them to access the wanna-build database of their - architecture. This has been the case even before ftp-master was - restricted; As wanna-build does a database-level lock when - accessing, even reading, the data, you had to be in the right - group (wb-<arch>) to be able to directly access a - wanna-build database. - </p> - <p>That said, you can see what state a package is in by - going to <a href="https://buildd.debian.org/stats/">the buildd - stats page</a>, except if it is in state <em>installed</em> - (well, not unless you don't mind digging through the - multi-megabytes "<arch>-all.txt" files...). - </p> - <h2>The build log results</h2> - <p> - When a package is built by sbuild (the buildd component which - does the actual building), a log with the build result is sent, - by mail, to the autobuilder admin and to logs@buildd.debian.org - (so that it can end up at https://buildd.debian.org). The build - log result can be one of <em>successful</em>, <em>attempted</em> (previously - known as <em>failed</em>), - <em>given-back</em>, or <em>skipped</em>. Note that, at <a - href="https://buildd.debian.org/">the buildd log overview - page</a>, the prefix <em>maybe-</em> is added, because among - other things, the fact that a build can be marked - <em>failed</em> there for things that aren't <em>really</em> a - failure has caused confusion in the past (or, the other way around, - sometimes a package which apparently built successful is really broken - and needs to be rebuilt).</p> - <p>The meaning of - the log results is as follows:</p> - <dl> - <dt><a name="successful">successful</a></dt> - <dd>The build was successful. When the autobuilder maintainer - receives this log, he will extract the embedded - <code>.changes</code> file, sign it, and send it back to the - autobuilder, which will cause the package to be uploaded.</dd> - <dt><a name="failed">attempted</a> (previously: failed)</dt> - <dd>The build exited with a non-zero exit state, indicating it probably - failed. As there can be a number of reasons why a build fails, - enumerating all them would be tedious, so no attempt is done here. If a - package of yours is marked <em>(maybe-)failed</em>, you will want to - read the above, and check its current wanna-build state. - </dd> - <dt><a name="given-back">given-back</a></dt> - <dd>The build failed due to a temporary problem with the - autobuilder; examples include network problems, the - unavailability of the packages' source with the current - sources.list, low disk space, and others.<br /> - A package which is <em>given-back</em> is marked as - <em><a href="#needs-build">needs-build</a></em> again; as - such, it will be automatically picked up by a different - autobuilder once one is ready. - </dd> - <dt><a name="skipped">skipped</a></dt> - <dd>In the time between the package was picked by the/an - autobuilder and marked <em><a - href="#building">building</a></em> and the build attempt, a new - version for this package was uploaded, or a porter manually - modified the wanna-build state for another reason. When that is - done, a mail is sent to the autobuilder, which will mark the - package as not to be built; sbuild sees this, and will skip the - build (although a build log with this result is sent, describing - the fact that this happened). - </dd> - </dl> - -<h2><a name="graphlink">The graphical version</a></h2> -<p>To illustrate the above, we have also provided a <a -href="wanna-build.png">flowchart-version</a> of this procedure. Again, note -that it does not contain everything mentioned in this document. -</p> diff --git a/greek/devel/constitution.1.0.wml b/greek/devel/constitution.1.0.wml deleted file mode 100644 index 3c8adc00d0d..00000000000 --- a/greek/devel/constitution.1.0.wml +++ /dev/null @@ -1,901 +0,0 @@ -#use wml::debian::template title="Historical Debian Constitution v 1.0" BARETITLE="true" -#use wml::debian::translation-check translation="ba01cfdc529712e3626bdf15fd37d39e94126794" maintainer="galaxico" - -<h1>Historical version of the Constitution for the Debian Project (v1.0)</h1> - -<p>Version 1.0 ratified on December 2nd, 1998. Superseded by -<a href="constitution.1.1">Version 1.1</a> ratified on June 21st, -2003, which is itself superseded by <a href="constitution.1.2">version 1.2</a>, -ratified on October 29th, 2003. Version 1.2 was again superseded by -<a href="constitution.1.3">version 1.3</a> ratified on September 24th, 2006. -Version 1.3 was again superseded by <a href="constitution.1.4">version 1.4</a> -ratified on October 7th, 2007. -That was superseded by the <a href="constitution.1.5">version 1.5</a> -ratified on January 9th, 2015, and again superseeded by the -<a href="constitution.1.6">version 1.6</a>, ratified on December 13th, 2015. -That was superseeded by the <a href="constitution">current version 1.7</a>, -ratified on August 14th, 2016. -</p> - - -<h2>1. Introduction</h2> - -<p><cite>The Debian Project is an association of individuals who have -made common cause to create a free operating system.</cite></p> - -<p>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.</p> - -<h2>2. Decision-making bodies and individuals</h2> - -<p>Each decision in the Project is made by one or more of the -following:</p> - -<ol> - <li>The Developers, by way of General Resolution or an election;</li> - - <li>The Project Leader;</li> - - <li>The Technical Committee and/or its Chairman;</li> - - <li>The individual Developer working on a particular task;</li> - - <li>Delegates appointed by the Project Leader for specific - tasks;</li> - - <li>The Project Secretary.</li> -</ol> - -<p>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. <cite>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.</cite></p> - -<h3>2.1. General rules</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>A person may leave the Project or resign from a particular post - they hold, at any time, by stating so publicly.</p> - </li> -</ol> - -<h2>3. Individual Developers</h2> - -<h3>3.1. Powers</h3> - -<p>An individual Developer may</p> - -<ol> - <li>make any technical or nontechnical decision with regard to their - own work;</li> - - <li>propose or sponsor draft General Resolutions;</li> - - <li>propose themselves as a Project Leader candidate in - elections;</li> - - <li>vote on General Resolutions and in Leadership elections.</li> -</ol> - -<h3>3.2. Composition and appointment</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>The Project Leader's Delegate(s) may choose not to admit new - Developers, or expel existing Developers. <cite>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.</cite></p> - </li> -</ol> - -<h3>3.3. Procedure</h3> - -<p>Developers may make these decisions as they see fit.</p> - -<h2>4. The Developers by way of General Resolution or election</h2> - -<h3>4.1. Powers</h3> - -<p>Together, the Developers may:</p> - -<ol> - <li> - <p>Appoint or recall the Project Leader.</p> - </li> - - <li> - <p>Amend this constitution, provided they agree with a 3:1 - majority.</p> - </li> - - <li> - <p>Override any decision by the Project Leader or a Delegate.</p> - </li> - - <li> - <p>Override any decision by the Technical Committee, provided they - agree with a 2:1 majority.</p> - </li> - - <li> - <p>Issue nontechnical policy documents and statements.</p> - - <p>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.</p> - - <p>They may also include position statements about issues of the - day.</p> - </li> - - <li> - <p>Together with the Project Leader and SPI, make decisions about - property held in trust for purposes related to Debian. (See - §9.1.)</p> - </li> -</ol> - -<h3>4.2. Procedure</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>Delaying a decision by the Project Leader or their Delegate:</p> - - <ol> - <li>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 §4.1(3).</li> - - <li>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).</li> - - <li>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.</li> - - <li>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.</li> - - <li>If the Project Leader (or the Delegate) withdraws the - original decision, the vote becomes moot, and is no longer - conducted.</li> - </ol> - </li> - - <li> - <p>Votes are taken by the Project Secretary. Votes and tallies - results are not be 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, and may be ended by the Project Secretary when the outcome - of a vote is no longer in doubt.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>Votes are cast by email in a manner suitable to the Secretary. - The Secretary determines for each poll whether voters can change - their votes.</p> - </li> - - <li> - <p>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.</p> - </li> -</ol> - -<h2>5. Project Leader</h2> - -<h3>5.1. Powers</h3> - -<p>The <a href="leader">Project Leader</a> may:</p> - -<ol> - <li> - <p>Appoint Delegates or delegate decisions to the Technical - Committee.</p> - - <p>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.</p> - - <p>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.</p> - </li> - - <li> - <p>Lend authority to other Developers.</p> - - <p>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.</p> - </li> - - <li> - <p>Make any decision which requires urgent action.</p> - - <p>This does not apply to decisions which have only become - gradually urgent through lack of relevant action, unless there is a - fixed deadline.</p> - </li> - - <li> - <p>Make any decision for whom noone else has responsibility.</p> - </li> - - <li> - <p>Propose draft General Resolutions and amendments.</p> - </li> - - <li> - <p>Together with the Technical Committee, appoint new members to - the Committee. (See §6.2.)</p> - </li> - - <li> - <p>Use a casting vote when Developers vote.</p> - - <p>The Project Leader also has a normal vote in such ballots.</p> - </li> - - <li> - <p>Vary the discussion period for Developers' votes (as above).</p> - </li> - - <li> - <p>Lead discussions amongst Developers.</p> - - <p>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.</p> - </li> - - <li> - <p>Together with SPI, make decisions affecting property held in - trust for purposes related to Debian. (See §9.1.)</p> - </li> -</ol> - -<h3>5.2. Appointment</h3> - -<ol> - <li>The Project Leader is elected by the Developers.</li> - - <li>The election begins nine weeks before the leadership post becomes - vacant, or (if it is too late already) immediately.</li> - - <li>For the following three weeks any Developer may nominate - themselves as a candidate Project Leader.</li> - - <li>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.</li> - - <li>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.</li> - - <li>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.</li> - - <li>The decision will be made using Concorde Vote Counting. The - quorum is the same as for a General Resolution (§4.2) and the - default option is None Of The Above.</li> - - <li>The Project Leader serves for one year from their election.</li> -</ol> - -<h3>5.3. Procedure</h3> - -<p>The Project Leader should attempt to make decisions which are -consistent with the consensus of the opinions of the Developers.</p> - -<p>Where practical the Project Leader should informally solicit the -views of the Developers.</p> - -<p>The Project Leader should avoid overemphasizing their own point of -view when making decisions in their capacity as Leader.</p> - -<h2>6. Technical committee</h2> - -<h3>6.1. Powers</h3> - -<p>The <a href="tech-ctte">Technical Committee</a> may:</p> - -<ol> - <li> - <p>Decide on any matter of technical policy.</p> - - <p>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).)</p> - </li> - - <li> - <p>Decide any technical matter where Developers' jurisdictions - overlap.</p> - - <p>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.</p> - </li> - - <li> - <p>Make a decision when asked to do so.</p> - - <p>Any person or body may delegate a decision of their own to the - Technical Committee, or seek advice from it.</p> - </li> - - <li> - <p>Overrule a Developer (requires a 3:1 majority).</p> - - <p>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.</p> - </li> - - <li> - <p>Offer advice.</p> - - <p>The Technical Committee may make formal announcements about its - views on any matter. <cite>Individual members may of course make - informal statements about their views and about the likely views of - the committee.</cite></p> - </li> - - <li> - <p>Together with the Project Leader, appoint new members to itself - or remove existing members. (See §6.2.)</p> - </li> - - <li> - <p>Appoint the Chairman of the Technical Committee.</p> - - <p>The Chairman is elected by the Committee from its members. All - members of the committee are automatically nominated; the committee - vote 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 None Of The Above option. The vote finishes - when all the members have voted or when the outcome is no longer in - doubt. The result is determined according to Concorde Vote - Counting.</p> - </li> - - <li> - <p>The Chairman can stand in for the Leader, together with the - Secretary</p> - - <p>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.</p> - </li> -</ol> - -<h3>6.2. Composition</h3> - -<ol> - <li> - <p>The Technical Committee consists of up to 8 Developers, and - should usually have at least 4 members.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>When there are 5 members or fewer the Technical Committee may - appoint new member(s) until the number of members reaches 6.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>If the Technical Committee and the Project Leader agree they - may remove or replace an existing member of the Technical - Committee.</p> - </li> -</ol> - -<h3>6.3. Procedure</h3> - -<ol> - <li> - <p>The Technical Committee uses the Standard Resolution - Procedure.</p> - - <p>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.</p> - </li> - - <li> - <p>Details regarding voting</p> - - <p>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).</p> - </li> - - <li> - <p>Public discussion and decision-making.</p> - - <p>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.</p> - </li> - - <li> - <p>Confidentiality of appointments.</p> - - <p>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.</p> - </li> - - <li> - <p>No detailed design work.</p> - - <p>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.</p> - - <p>The Technical Committee restricts itself to choosing from or - adopting compromises between solutions and decisions which have - been proposed and reasonably thoroughly discussed elsewhere.</p> - - <p><cite>Individual members of the technical committee may of - course participate on their own behalf in any aspect of design and - policy work.</cite></p> - </li> - - <li> - <p>Technical Committee makes decisions only as last resort.</p> - - <p>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.</p> - </li> -</ol> - -<h2>7. The Project Secretary</h2> - -<h3>7.1. Powers</h3> - -<p>The <a href="secretary">Secretary</a>:</p> - -<ol> - <li> - <p>Takes votes amongst the Developers, and determines the number - and identity of Developers, whenever this is required by the - constitution.</p> - </li> - - <li> - <p>Can stand in for the Leader, together with the Chairman of the - Technical Committee.</p> - - <p>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.</p> - </li> - - <li> - <p>Adjudicates any disputes about interpretation of the - constitution.</p> - </li> - - <li> - <p>May delegate part or all of their authority to someone else, or - withdraw such a delegation at any time.</p> - </li> -</ol> - -<h3>7.2. Appointment</h3> - -<p>The Project Secretary is appointed by the Project Leader and the -current Project Secretary.</p> - -<p>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.</p> - -<p>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.</p> - -<p>The Project Secretary's term of office is 1 year, at which point -they or another Secretary must be (re)appointed.</p> - -<h3>7.3. Procedure</h3> - -<p>The Project Secretary should make decisions which are fair and -reasonable, and preferably consistent with the consensus of the -Developers.</p> - -<p>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.</p> - -<h2>8. The Project Leader's Delegates</h2> - -<h3>8.1. Powers</h3> - -<p>The Project Leader's Delegates:</p> - -<ol> - <li>have powers delegated to them by the Project Leader;</li> - - <li>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. <cite>This is to - avoid concentration of power, particularly over membership as a - Developer, in the hands of the Project Leader.</cite></li> -</ol> - -<h3>8.2. Appointment</h3> - -<p>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.</p> - -<h3>8.3. Procedure</h3> - -<p>Delegates may make decisions as they see fit, but should attempt to -implement good technical decisions and/or follow consensus opinion.</p> - -<h2>9. Software in the Public Interest</h2> - -<p><a href="https://www.spi-inc.org/">SPI</a> and Debian are separate -organisations who share some goals. Debian is grateful for the legal -support framework offered by SPI. <cite>Debian's Developers are -currently members of SPI by virtue of their status as -Developers.</cite></p> - -<h3>9.1. Authority</h3> - -<ol> - <li>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.</li> - - <li>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.</li> - - <li>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.</li> -</ol> - -<h3>9.2. Management of property for purposes related to Debian</h3> - -<p>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.</p> - -<p>SPI have made the following undertakings:</p> - -<ol> - <li>SPI will hold money, trademarks and other tangible and intangible - property and manage other affairs for purposes related to - Debian.</li> - - <li>Such property will be accounted for separately and held in trust - for those purposes, decided on by Debian and SPI according to this - section.</li> - - <li>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.</li> - - <li>SPI will consider using or disposing of property held in trust - for Debian when asked to do so by the Project Leader.</li> - - <li>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.</li> - - <li>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.</li> -</ol> - -<h2>A. Standard Resolution Procedure</h2> - -<p>These rules apply to communal decision-making by committees and -plebiscites, where stated above.</p> - -<h3>A.1. Proposal</h3> - -<p>The formal procedure begins when a draft resolution is proposed and -sponsored, as required.</p> - -<h3>A.1. Discussion and Amendment</h3> - -<ol> - <li>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.</li> - - <li>A formal amendment may be accepted by the resolution's proposer, - in which case the formal resolution draft is immediately changed to - match.</li> - - <li>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.</li> - - <li>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).)</li> - - <li>The proposer of a resolution may suggest changes to the wordings - of amendments; these take effect if the proposer of the amendment - agrees and none of the sponsors object. In this case the changed - amendments will be voted on instead of the originals.</li> - - <li>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.</li> -</ol> - -<h3>A.2. Calling for a vote</h3> - -<ol> - <li>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.</li> - - <li>The proposer or a sponsor of a motion may call for a vote on any - or all of the amendments individually or together; the proposer or - sponsor of an amendment may call for a vote only on that amendment - and related amendments.</li> - - <li>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(6).</li> - - <li>The minimum discussion period is counted from the time the last - formal amendment was accepted, or the last related formal amendment - was accepted if an amendment is being voted on, or since the whole - resolution was proposed if no amendments have been proposed and - accepted.</li> -</ol> - -<h3>A.3. Voting procedure</h3> - -<ol> - <li>Each independent set of related amendments is voted on in a - separate ballot. Each such ballot has as options all the sensible - combinations of amendments and options, and an option Further - Discussion. If Further Discussion wins then the entire resolution - procedure is set back to the start of the discussion period. No - quorum is required for an amendment.</li> - - <li>When the final form of the resolution has been determined it is - voted on in a final ballot, in which the options are Yes, No and - Further Discussion. If Further Discussion wins then the entire - procedure is set back to the start of the discussion period.</li> - - <li>The vote taker (if there is one) or the voters (if voting is done - by public pronouncement) may arrange for these ballots to be held - simultaneously, even (for example) using a single voting message. If - amendment ballot(s) and the final ballot are combined in this way - then it must be possible for a voter to vote differently in the final - ballot for each of the possible forms of the final draft - resolution.</li> - - <li>Votes may be cast during the voting period, as specified - elsewhere. If the voting period can end if the outcome is no longer - in doubt, the possibility that voters may change their votes is not - considered.</li> - - <li>The votes are counted according to the Concorde Vote Counting. If - a quorum is required then the default option is Further - Discussion.</li> - - <li>In cases of doubt the Project Secretary shall decide on matters - of procedure (for example, whether particular amendments should be - considered independent or not).</li> -</ol> - -<h3>A.4. Withdrawing resolutions or unaccepted amendments</h3> - -<p>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.</p> - -<p>A sponsor of a resolution or amendment (unless it has been -accepted) may withdraw.</p> - -<p>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.</p> - -<h3>A.5. Expiry</h3> - -<p>If a proposed resolution has not been discussed, amended, voted on -or otherwise dealt with for 4 weeks then it is considered to have been -withdrawn.</p> - -<h3>A.6. Concorde Vote Counting</h3> - -<ol> - <li>This is used to determine the winner amongst a list of options. - Each ballot paper gives a ranking of the voter's preferred options. - (The ranking need not be complete.)</li> - - <li>Option A is said to Dominate option B if strictly more ballots - prefer A to B than prefer B to A.</li> - - <li>All options which are Dominated by at least one other option are - discarded, and references to them in ballot papers will be - ignored.</li> - - <li>If there is any option which Dominates all others then that is - the winner.</li> - - <li> - If there is now more than one option remaining Single Transferrable - Vote will be applied to choose amongst those remaining: - - <ul> - <li>The number of first preferences for each option is counted, - and if any option has more than half it is the winner.</li> - - <li>Otherwise the option with the lowest number of first - preferences is eliminated and its votes redistributed according - to the second preferences.</li> - - <li>This elimination procedure is repeated, moving down ballot - papers to 2nd, 3rd, 4th, etc. preferences as required, until one - option gets more than half of the <q>first</q> preferences.</li> - </ul> - </li> - - <li>In the case of ties the elector with a casting vote will decide. - The casting vote does not count as a normal vote; however that - elector will usually also get a normal vote.</li> - - <li>If a supermajority is required the number of Yes votes in the - final ballot is reduced by an appropriate factor. Strictly speaking, - for a supermajority of F:A, the number of ballots which prefer Yes to - X (when considering whether Yes Dominates X or X Dominates Yes) or - the number of ballots whose first (remaining) preference is Yes (when - doing STV comparisons for winner and elimination purposes) is - multiplied by a factor A/F before the comparison is done. <cite>This - means that a 2:1 vote, for example, means twice as many people voted - for as against; abstentions are not counted.</cite></li> - - <li>If a quorum is required, there must be at least that many votes - which prefer the winning option to the default option. If there are - not then the default option wins after all. For votes requiring a - supermajority, the actual number of Yes votes is used when checking - whether the quorum has been reached.</li> -</ol> - -<p><cite>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.</cite></p> - -<h2>B. Use of language and typography</h2> - -<p>The present indicative (<q>is</q>, for example) means that the statement -is a rule in this constitution. <q>May</q> or <q>can</q> indicates that the -person or body has discretion. <q>Should</q> means that it would be -considered a good thing if the sentence were obeyed, but it is not -binding. <cite>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.</cite></p> diff --git a/greek/devel/constitution.1.1.wml b/greek/devel/constitution.1.1.wml deleted file mode 100644 index 4b6e35c6bff..00000000000 --- a/greek/devel/constitution.1.1.wml +++ /dev/null @@ -1,937 +0,0 @@ -#use wml::debian::template title="Historical Debian Constitution v 1.1" BARETITLE="true" -#use wml::debian::translation-check translation="ba01cfdc529712e3626bdf15fd37d39e94126794" maintainer="galaxico" - -<h1>Historical version of the Constitution for the Debian Project (v1.1)</h1> - -<p>Version 1.1 ratified on June 21st, 2003. Supersedes -<a href="constitution.1.0">Version 1.0</a> ratified on December 2nd, -1998. Superseded by <a href="constitution.1.2">version 1.2</a>, ratified on October -29th, 2003, which was again superseded by <a href="constitution.1.3">version 1.3</a> -ratified on September 24th, 2006. -Version 1.3 was again superseded by <a href="constitution.1.4">version 1.4</a> -ratified on October 7th, 2007. -That was superseded by the <a href="constitution.1.5">version 1.5</a> -ratified on January 9th, 2015, and again superseeded by the -<a href="constitution.1.6">version 1.6</a>, ratified on December 13th, 2015. -That was superseeded by the <a href="constitution">current version 1.7</a>, -ratified on August 14th, 2016. -</p> - - -<h2>1. Introduction</h2> - -<p><cite>The Debian Project is an association of individuals who have -made common cause to create a free operating system.</cite></p> - -<p>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.</p> - -<h2>2. Decision-making bodies and individuals</h2> - -<p>Each decision in the Project is made by one or more of the -following:</p> - -<ol> - <li>The Developers, by way of General Resolution or an election;</li> - - <li>The Project Leader;</li> - - <li>The Technical Committee and/or its Chairman;</li> - - <li>The individual Developer working on a particular task;</li> - - <li>Delegates appointed by the Project Leader for specific - tasks;</li> - - <li>The Project Secretary.</li> -</ol> - -<p>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. <cite>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.</cite></p> - -<h3>2.1. General rules</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>A person may leave the Project or resign from a particular post - they hold, at any time, by stating so publicly.</p> - </li> -</ol> - -<h2>3. Individual Developers</h2> - -<h3>3.1. Powers</h3> - -<p>An individual Developer may</p> - -<ol> - <li>make any technical or nontechnical decision with regard to their - own work;</li> - - <li>propose or sponsor draft General Resolutions;</li> - - <li>propose themselves as a Project Leader candidate in - elections;</li> - - <li>vote on General Resolutions and in Leadership elections.</li> -</ol> - -<h3>3.2. Composition and appointment</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>The Project Leader's Delegate(s) may choose not to admit new - Developers, or expel existing Developers. <cite>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.</cite></p> - </li> -</ol> - -<h3>3.3. Procedure</h3> - -<p>Developers may make these decisions as they see fit.</p> - -<h2>4. The Developers by way of General Resolution or election</h2> - -<h3>4.1. Powers</h3> - -<p>Together, the Developers may:</p> - -<ol> - <li> - <p>Appoint or recall the Project Leader.</p> - </li> - - <li> - <p>Amend this constitution, provided they agree with a 3:1 - majority.</p> - </li> - - <li> - <p>Override any decision by the Project Leader or a Delegate.</p> - </li> - - <li> - <p>Override any decision by the Technical Committee, provided they - agree with a 2:1 majority.</p> - </li> - - <li> - <p>Issue nontechnical policy documents and statements.</p> - - <p>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.</p> - - <p>They may also include position statements about issues of the - day.</p> - </li> - - <li> - <p>Together with the Project Leader and SPI, make decisions about - property held in trust for purposes related to Debian. (See - §9.1.)</p> - </li> -</ol> - -<h3>4.2. Procedure</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>Delaying a decision by the Project Leader or their Delegate:</p> - - <ol> - <li>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 §4.1(3).</li> - - <li>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).</li> - - <li>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.</li> - - <li>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.</li> - - <li>If the Project Leader (or the Delegate) withdraws the - original decision, the vote becomes moot, and is no longer - conducted.</li> - </ol> - </li> - - <li> - <p> - 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. - </p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>Votes are cast by email in a manner suitable to the Secretary. - The Secretary determines for each poll whether voters can change - their votes.</p> - </li> - - <li> - <p>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.</p> - </li> -</ol> - -<h2>5. Project Leader</h2> - -<h3>5.1. Powers</h3> - -<p>The <a href="leader">Project Leader</a> may:</p> - -<ol> - <li> - <p>Appoint Delegates or delegate decisions to the Technical - Committee.</p> - - <p>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.</p> - - <p>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.</p> - </li> - - <li> - <p>Lend authority to other Developers.</p> - - <p>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.</p> - </li> - - <li> - <p>Make any decision which requires urgent action.</p> - - <p>This does not apply to decisions which have only become - gradually urgent through lack of relevant action, unless there is a - fixed deadline.</p> - </li> - - <li> - <p>Make any decision for whom noone else has responsibility.</p> - </li> - - <li> - <p>Propose draft General Resolutions and amendments.</p> - </li> - - <li> - <p>Together with the Technical Committee, appoint new members to - the Committee. (See §6.2.)</p> - </li> - - <li> - <p>Use a casting vote when Developers vote.</p> - - <p>The Project Leader also has a normal vote in such ballots.</p> - </li> - - <li> - <p>Vary the discussion period for Developers' votes (as above).</p> - </li> - - <li> - <p>Lead discussions amongst Developers.</p> - - <p>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.</p> - </li> - - <li> - <p>Together with SPI, make decisions affecting property held in - trust for purposes related to Debian. (See §9.1.)</p> - </li> -</ol> - -<h3>5.2. Appointment</h3> - -<ol> - <li>The Project Leader is elected by the Developers.</li> - - <li>The election begins nine weeks before the leadership post becomes - vacant, or (if it is too late already) immediately.</li> - - <li>For the following three weeks any Developer may nominate - themselves as a candidate Project Leader.</li> - - <li>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.</li> - - <li>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.</li> - - <li>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.</li> - - <li> - 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 <q>None Of The Above</q>. - </li> - - <li>The Project Leader serves for one year from their election.</li> -</ol> - -<h3>5.3. Procedure</h3> - -<p>The Project Leader should attempt to make decisions which are -consistent with the consensus of the opinions of the Developers.</p> - -<p>Where practical the Project Leader should informally solicit the -views of the Developers.</p> - -<p>The Project Leader should avoid overemphasizing their own point of -view when making decisions in their capacity as Leader.</p> - -<h2>6. Technical committee</h2> - -<h3>6.1. Powers</h3> - -<p>The <a href="tech-ctte">Technical Committee</a> may:</p> - -<ol> - <li> - <p>Decide on any matter of technical policy.</p> - - <p>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).)</p> - </li> - - <li> - <p>Decide any technical matter where Developers' jurisdictions - overlap.</p> - - <p>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.</p> - </li> - - <li> - <p>Make a decision when asked to do so.</p> - - <p>Any person or body may delegate a decision of their own to the - Technical Committee, or seek advice from it.</p> - </li> - - <li> - <p>Overrule a Developer (requires a 3:1 majority).</p> - - <p>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.</p> - </li> - - <li> - <p>Offer advice.</p> - - <p>The Technical Committee may make formal announcements about its - views on any matter. <cite>Individual members may of course make - informal statements about their views and about the likely views of - the committee.</cite></p> - </li> - - <li> - <p>Together with the Project Leader, appoint new members to itself - or remove existing members. (See §6.2.)</p> - </li> - - <li> - <p>Appoint the Chairman of the Technical Committee.</p> - - <p> - 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. - </p> - </li> - - <li> - <p>The Chairman can stand in for the Leader, together with the - Secretary</p> - - <p>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.</p> - </li> -</ol> - -<h3>6.2. Composition</h3> - -<ol> - <li> - <p>The Technical Committee consists of up to 8 Developers, and - should usually have at least 4 members.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>When there are 5 members or fewer the Technical Committee may - appoint new member(s) until the number of members reaches 6.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>If the Technical Committee and the Project Leader agree they - may remove or replace an existing member of the Technical - Committee.</p> - </li> -</ol> - -<h3>6.3. Procedure</h3> - -<ol> - <li> - <p>The Technical Committee uses the Standard Resolution - Procedure.</p> - - <p>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.</p> - </li> - - <li> - <p>Details regarding voting</p> - - <p>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).</p> - </li> - - <li> - <p>Public discussion and decision-making.</p> - - <p>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.</p> - </li> - - <li> - <p>Confidentiality of appointments.</p> - - <p>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.</p> - </li> - - <li> - <p>No detailed design work.</p> - - <p>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.</p> - - <p>The Technical Committee restricts itself to choosing from or - adopting compromises between solutions and decisions which have - been proposed and reasonably thoroughly discussed elsewhere.</p> - - <p><cite>Individual members of the technical committee may of - course participate on their own behalf in any aspect of design and - policy work.</cite></p> - </li> - - <li> - <p>Technical Committee makes decisions only as last resort.</p> - - <p>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.</p> - </li> -</ol> - -<h2>7. The Project Secretary</h2> - -<h3>7.1. Powers</h3> - -<p>The <a href="secretary">Secretary</a>:</p> - -<ol> - <li> - <p>Takes votes amongst the Developers, and determines the number - and identity of Developers, whenever this is required by the - constitution.</p> - </li> - - <li> - <p>Can stand in for the Leader, together with the Chairman of the - Technical Committee.</p> - - <p>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.</p> - </li> - - <li> - <p>Adjudicates any disputes about interpretation of the - constitution.</p> - </li> - - <li> - <p>May delegate part or all of their authority to someone else, or - withdraw such a delegation at any time.</p> - </li> -</ol> - -<h3>7.2. Appointment</h3> - -<p>The Project Secretary is appointed by the Project Leader and the -current Project Secretary.</p> - -<p>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.</p> - -<p>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.</p> - -<p>The Project Secretary's term of office is 1 year, at which point -they or another Secretary must be (re)appointed.</p> - -<h3>7.3. Procedure</h3> - -<p>The Project Secretary should make decisions which are fair and -reasonable, and preferably consistent with the consensus of the -Developers.</p> - -<p>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.</p> - -<h2>8. The Project Leader's Delegates</h2> - -<h3>8.1. Powers</h3> - -<p>The Project Leader's Delegates:</p> - -<ol> - <li>have powers delegated to them by the Project Leader;</li> - - <li>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. <cite>This is to - avoid concentration of power, particularly over membership as a - Developer, in the hands of the Project Leader.</cite></li> -</ol> - -<h3>8.2. Appointment</h3> - -<p>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.</p> - -<h3>8.3. Procedure</h3> - -<p>Delegates may make decisions as they see fit, but should attempt to -implement good technical decisions and/or follow consensus opinion.</p> - -<h2>9. Software in the Public Interest</h2> - -<p><a href="https://www.spi-inc.org/">SPI</a> and Debian are separate -organisations who share some goals. -Debian is grateful for the legal support framework offered by SPI. -<cite>Debian's Developers are currently members of SPI by virtue of -their status as Developers.</cite></p> - -<h3>9.1. Authority</h3> - -<ol> - <li>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.</li> - - <li>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.</li> - - <li>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.</li> -</ol> - -<h3>9.2. Management of property for purposes related to Debian</h3> - -<p>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.</p> - -<p>SPI have made the following undertakings:</p> - -<ol> - <li>SPI will hold money, trademarks and other tangible and intangible - property and manage other affairs for purposes related to - Debian.</li> - - <li>Such property will be accounted for separately and held in trust - for those purposes, decided on by Debian and SPI according to this - section.</li> - - <li>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.</li> - - <li>SPI will consider using or disposing of property held in trust - for Debian when asked to do so by the Project Leader.</li> - - <li>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.</li> - - <li>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.</li> -</ol> - -<h2>A. Standard Resolution Procedure</h2> - -<p>These rules apply to communal decision-making by committees and -plebiscites, where stated above.</p> - -<h3>A.1. Proposal</h3> - -<p>The formal procedure begins when a draft resolution is proposed and -sponsored, as required.</p> - -<h3>A.1. Discussion and Amendment</h3> - -<ol> - <li>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.</li> - - <li>A formal amendment may be accepted by the resolution's proposer, - in which case the formal resolution draft is immediately changed to - match.</li> - - <li>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.</li> - - <li>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).)</li> - - <li>The proposer of a resolution may suggest changes to the wordings - of amendments; these take effect if the proposer of the amendment - agrees and none of the sponsors object. In this case the changed - amendments will be voted on instead of the originals.</li> - - <li>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.</li> -</ol> - -<h3>A.2. Calling for a vote</h3> - -<ol> - <li>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.</li> - - <li> - The proposer or any sponsor of a resolution may call for a vote on that - resolution and all related amendments. - </li> - - <li>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).</li> - - <li> - 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. - </li> -</ol> - -<h3>A.3. Voting procedure</h3> - -<ol> - <li> - 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). - </li> - - <li> - The default option must not have any supermajority requirements. - Options which do not have an explicit supermajority requirement - have a 1:1 majority requirement. - </li> - - <li> - The votes are counted according to the rules in A.6. The - default option is <q>Further Discussion</q>, unless specified - otherwise. - </li> - - <li>In cases of doubt the Project Secretary shall decide on matters - of procedure.</li> -</ol> - -<h3>A.4. Withdrawing resolutions or unaccepted amendments</h3> - -<p>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.</p> - -<p>A sponsor of a resolution or amendment (unless it has been -accepted) may withdraw.</p> - -<p>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.</p> - -<h3>A.5. Expiry</h3> - -<p> - 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. -</p> - -<p> - The secretary may also include suggestions on how to proceed, - if appropriate. -</p> - -<h3>A.6. Vote Counting</h3> - -<ol> - <li> 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. - </li> - <li> 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. - </li> - <li> Any (non-default) option which does not defeat the default option - by its required majority ratio is dropped from consideration. - <ol> - <li> - Given two options A and B, V(A,B) is the number of voters - who prefer option A over option B. - </li> - <li> - 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). - </li> - <li> - If a supermajority of S:1 is required for A, its majority ratio - is S; otherwise, its majority ratio is 1. - </li> - </ol> - </li> - <li> From the list of undropped options, we generate a list of - pairwise defeats. - <ol> - <li> - An option A defeats an option B, if V(A,B) is strictly greater - than V(B,A). - </li> - </ol> - </li> - <li> From the list of [undropped] pairwise defeats, we generate a - set of transitive defeats. - <ol> - <li> - 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. - </li> - </ol> - </li> - <li> We construct the Schwartz set from the set of transitive defeats. - <ol> - <li> - 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. - </li> - </ol> - </li> - <li> 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. - <ol> - <li> - 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). - </li> - <li> - A weakest defeat is a defeat that has no other defeat weaker - than it. There may be more than one such defeat. - </li> - </ol> - </li> - <li> 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. - </li> -</ol> - -<p> - <strong>Note:</strong> 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. -</p> - -<p><cite>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.</cite></p> - -<h2>B. Use of language and typography</h2> - -<p>The present indicative (<q>is</q>, for example) means that the statement -is a rule in this constitution. <q>May</q> or <q>can</q> indicates that the -person or body has discretion. <q>Should</q> means that it would be -considered a good thing if the sentence were obeyed, but it is not -binding. <cite>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.</cite></p> diff --git a/greek/devel/constitution.1.2.wml b/greek/devel/constitution.1.2.wml deleted file mode 100644 index d9d47138633..00000000000 --- a/greek/devel/constitution.1.2.wml +++ /dev/null @@ -1,950 +0,0 @@ -#use wml::debian::template title="Historical Debian Constitution v 1.2" BARETITLE="true" -#use wml::debian::translation-check translation="ba01cfdc529712e3626bdf15fd37d39e94126794" maintainer="galaxico" - -<h1>Historical version of the Constitution for the Debian Project (v1.2)</h1> - -<p>Version 1.2 ratified on October 29th, 2003. Supersedes -<a href="constitution.1.1">Version 1.1</a> ratified on June 21st, -2003, which itself supersedes <a href="constitution.1.0">Version 1.0</a> -ratified on December 2nd, 1998. -Superseded by <a href="constitution.1.3">version 1.3</a>, ratified on September -24th, 2006. -Version 1.3 was again superseded by <a href="constitution.1.4">version 1.4</a> -ratified on October 7th, 2007. -That was superseded by the <a href="constitution.1.5">version 1.5</a> -ratified on January 9th, 2015, and again superseeded by the -<a href="constitution.1.6">version 1.6</a>, ratified on December 13th, 2015. -That was superseeded by the <a href="constitution">current version 1.7</a>, -ratified on August 14th, 2016. -</p> - -<h2>1. Introduction</h2> - -<p><cite>The Debian Project is an association of individuals who have -made common cause to create a free operating system.</cite></p> - -<p>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.</p> - -<h2>2. Decision-making bodies and individuals</h2> - -<p>Each decision in the Project is made by one or more of the -following:</p> - -<ol> - <li>The Developers, by way of General Resolution or an election;</li> - - <li>The Project Leader;</li> - - <li>The Technical Committee and/or its Chairman;</li> - - <li>The individual Developer working on a particular task;</li> - - <li>Delegates appointed by the Project Leader for specific - tasks;</li> - - <li>The Project Secretary.</li> -</ol> - -<p>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. <cite>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.</cite></p> - -<h3>2.1. General rules</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>A person may leave the Project or resign from a particular post - they hold, at any time, by stating so publicly.</p> - </li> -</ol> - -<h2>3. Individual Developers</h2> - -<h3>3.1. Powers</h3> - -<p>An individual Developer may</p> - -<ol> - <li>make any technical or nontechnical decision with regard to their - own work;</li> - - <li>propose or sponsor draft General Resolutions;</li> - - <li>propose themselves as a Project Leader candidate in - elections;</li> - - <li>vote on General Resolutions and in Leadership elections.</li> -</ol> - -<h3>3.2. Composition and appointment</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>The Project Leader's Delegate(s) may choose not to admit new - Developers, or expel existing Developers. <cite>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.</cite></p> - </li> -</ol> - -<h3>3.3. Procedure</h3> - -<p>Developers may make these decisions as they see fit.</p> - -<h2>4. The Developers by way of General Resolution or election</h2> - -<h3>4.1. Powers</h3> - -<p>Together, the Developers may:</p> - -<ol> - <li> - <p>Appoint or recall the Project Leader.</p> - </li> - - <li> - <p>Amend this constitution, provided they agree with a 3:1 - majority.</p> - </li> - - <li> - <p>Override any decision by the Project Leader or a Delegate.</p> - </li> - - <li> - <p>Override any decision by the Technical Committee, provided they - agree with a 2:1 majority.</p> - </li> - - <li> - <p>Issue, supersede and withdraw nontechnical policy documents and - statements.</p> - - <p>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.</p> - - <p>They may also include position statements about issues of the - day.</p> - - <ol style="list-style: decimal;"> - <li>A Foundation Document is a document or statement regarded as - critical to the Project's mission and purposes.</li> - <li>The Foundation Documents are the works entitled <q>Debian - Social Contract</q> and <q>Debian Free Software Guidelines</q>.</li> - <li>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.</li> - </ol> - - </li> - - <li> - <p>Together with the Project Leader and SPI, make decisions about - property held in trust for purposes related to Debian. (See - §9.1.)</p> - </li> -</ol> - -<h3>4.2. Procedure</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>Delaying a decision by the Project Leader or their Delegate:</p> - - <ol> - <li>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 §4.1(3).</li> - - <li>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).</li> - - <li>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.</li> - - <li>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.</li> - - <li>If the Project Leader (or the Delegate) withdraws the - original decision, the vote becomes moot, and is no longer - conducted.</li> - </ol> - </li> - - <li> - <p> - 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. - </p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>Votes are cast by email in a manner suitable to the Secretary. - The Secretary determines for each poll whether voters can change - their votes.</p> - </li> - - <li> - <p>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.</p> - </li> -</ol> - -<h2>5. Project Leader</h2> - -<h3>5.1. Powers</h3> - -<p>The <a href="leader">Project Leader</a> may:</p> - -<ol> - <li> - <p>Appoint Delegates or delegate decisions to the Technical - Committee.</p> - - <p>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.</p> - - <p>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.</p> - </li> - - <li> - <p>Lend authority to other Developers.</p> - - <p>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.</p> - </li> - - <li> - <p>Make any decision which requires urgent action.</p> - - <p>This does not apply to decisions which have only become - gradually urgent through lack of relevant action, unless there is a - fixed deadline.</p> - </li> - - <li> - <p>Make any decision for whom noone else has responsibility.</p> - </li> - - <li> - <p>Propose draft General Resolutions and amendments.</p> - </li> - - <li> - <p>Together with the Technical Committee, appoint new members to - the Committee. (See §6.2.)</p> - </li> - - <li> - <p>Use a casting vote when Developers vote.</p> - - <p>The Project Leader also has a normal vote in such ballots.</p> - </li> - - <li> - <p>Vary the discussion period for Developers' votes (as above).</p> - </li> - - <li> - <p>Lead discussions amongst Developers.</p> - - <p>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.</p> - </li> - - <li> - <p>Together with SPI, make decisions affecting property held in - trust for purposes related to Debian. (See §9.1.)</p> - </li> -</ol> - -<h3>5.2. Appointment</h3> - -<ol> - <li>The Project Leader is elected by the Developers.</li> - - <li>The election begins nine weeks before the leadership post becomes - vacant, or (if it is too late already) immediately.</li> - - <li>For the following three weeks any Developer may nominate - themselves as a candidate Project Leader.</li> - - <li>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.</li> - - <li>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.</li> - - <li>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.</li> - - <li> - 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 <q>None Of The Above</q>. - </li> - - <li>The Project Leader serves for one year from their election.</li> -</ol> - -<h3>5.3. Procedure</h3> - -<p>The Project Leader should attempt to make decisions which are -consistent with the consensus of the opinions of the Developers.</p> - -<p>Where practical the Project Leader should informally solicit the -views of the Developers.</p> - -<p>The Project Leader should avoid overemphasizing their own point of -view when making decisions in their capacity as Leader.</p> - -<h2>6. Technical committee</h2> - -<h3>6.1. Powers</h3> - -<p>The <a href="tech-ctte">Technical Committee</a> may:</p> - -<ol> - <li> - <p>Decide on any matter of technical policy.</p> - - <p>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).)</p> - </li> - - <li> - <p>Decide any technical matter where Developers' jurisdictions - overlap.</p> - - <p>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.</p> - </li> - - <li> - <p>Make a decision when asked to do so.</p> - - <p>Any person or body may delegate a decision of their own to the - Technical Committee, or seek advice from it.</p> - </li> - - <li> - <p>Overrule a Developer (requires a 3:1 majority).</p> - - <p>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.</p> - </li> - - <li> - <p>Offer advice.</p> - - <p>The Technical Committee may make formal announcements about its - views on any matter. <cite>Individual members may of course make - informal statements about their views and about the likely views of - the committee.</cite></p> - </li> - - <li> - <p>Together with the Project Leader, appoint new members to itself - or remove existing members. (See §6.2.)</p> - </li> - - <li> - <p>Appoint the Chairman of the Technical Committee.</p> - - <p> - 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. - </p> - </li> - - <li> - <p>The Chairman can stand in for the Leader, together with the - Secretary</p> - - <p>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.</p> - </li> -</ol> - -<h3>6.2. Composition</h3> - -<ol> - <li> - <p>The Technical Committee consists of up to 8 Developers, and - should usually have at least 4 members.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>When there are 5 members or fewer the Technical Committee may - appoint new member(s) until the number of members reaches 6.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>If the Technical Committee and the Project Leader agree they - may remove or replace an existing member of the Technical - Committee.</p> - </li> -</ol> - -<h3>6.3. Procedure</h3> - -<ol> - <li> - <p>The Technical Committee uses the Standard Resolution - Procedure.</p> - - <p>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.</p> - </li> - - <li> - <p>Details regarding voting</p> - - <p>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).</p> - </li> - - <li> - <p>Public discussion and decision-making.</p> - - <p>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.</p> - </li> - - <li> - <p>Confidentiality of appointments.</p> - - <p>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.</p> - </li> - - <li> - <p>No detailed design work.</p> - - <p>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.</p> - - <p>The Technical Committee restricts itself to choosing from or - adopting compromises between solutions and decisions which have - been proposed and reasonably thoroughly discussed elsewhere.</p> - - <p><cite>Individual members of the technical committee may of - course participate on their own behalf in any aspect of design and - policy work.</cite></p> - </li> - - <li> - <p>Technical Committee makes decisions only as last resort.</p> - - <p>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.</p> - </li> -</ol> - -<h2>7. The Project Secretary</h2> - -<h3>7.1. Powers</h3> - -<p>The <a href="secretary">Secretary</a>:</p> - -<ol> - <li> - <p>Takes votes amongst the Developers, and determines the number - and identity of Developers, whenever this is required by the - constitution.</p> - </li> - - <li> - <p>Can stand in for the Leader, together with the Chairman of the - Technical Committee.</p> - - <p>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.</p> - </li> - - <li> - <p>Adjudicates any disputes about interpretation of the - constitution.</p> - </li> - - <li> - <p>May delegate part or all of their authority to someone else, or - withdraw such a delegation at any time.</p> - </li> -</ol> - -<h3>7.2. Appointment</h3> - -<p>The Project Secretary is appointed by the Project Leader and the -current Project Secretary.</p> - -<p>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.</p> - -<p>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.</p> - -<p>The Project Secretary's term of office is 1 year, at which point -they or another Secretary must be (re)appointed.</p> - -<h3>7.3. Procedure</h3> - -<p>The Project Secretary should make decisions which are fair and -reasonable, and preferably consistent with the consensus of the -Developers.</p> - -<p>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.</p> - -<h2>8. The Project Leader's Delegates</h2> - -<h3>8.1. Powers</h3> - -<p>The Project Leader's Delegates:</p> - -<ol> - <li>have powers delegated to them by the Project Leader;</li> - - <li>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. <cite>This is to - avoid concentration of power, particularly over membership as a - Developer, in the hands of the Project Leader.</cite></li> -</ol> - -<h3>8.2. Appointment</h3> - -<p>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.</p> - -<h3>8.3. Procedure</h3> - -<p>Delegates may make decisions as they see fit, but should attempt to -implement good technical decisions and/or follow consensus opinion.</p> - -<h2>9. Software in the Public Interest</h2> - -<p><a href="https://www.spi-inc.org/">SPI</a> and Debian are separate -organisations who share some goals. -Debian is grateful for the legal support framework offered by SPI. -<cite>Debian's Developers are currently members of SPI by virtue of -their status as Developers.</cite></p> - -<h3>9.1. Authority</h3> - -<ol> - <li>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.</li> - - <li>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.</li> - - <li>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.</li> -</ol> - -<h3>9.2. Management of property for purposes related to Debian</h3> - -<p>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.</p> - -<p>SPI have made the following undertakings:</p> - -<ol> - <li>SPI will hold money, trademarks and other tangible and intangible - property and manage other affairs for purposes related to - Debian.</li> - - <li>Such property will be accounted for separately and held in trust - for those purposes, decided on by Debian and SPI according to this - section.</li> - - <li>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.</li> - - <li>SPI will consider using or disposing of property held in trust - for Debian when asked to do so by the Project Leader.</li> - - <li>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.</li> - - <li>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.</li> -</ol> - -<h2>A. Standard Resolution Procedure</h2> - -<p>These rules apply to communal decision-making by committees and -plebiscites, where stated above.</p> - -<h3>A.1. Proposal</h3> - -<p>The formal procedure begins when a draft resolution is proposed and -sponsored, as required.</p> - -<h3>A.1. Discussion and Amendment</h3> - -<ol> - <li>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.</li> - - <li>A formal amendment may be accepted by the resolution's proposer, - in which case the formal resolution draft is immediately changed to - match.</li> - - <li>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.</li> - - <li>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).)</li> - - <li>The proposer of a resolution may suggest changes to the wordings - of amendments; these take effect if the proposer of the amendment - agrees and none of the sponsors object. In this case the changed - amendments will be voted on instead of the originals.</li> - - <li>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.</li> -</ol> - -<h3>A.2. Calling for a vote</h3> - -<ol> - <li>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.</li> - - <li> - The proposer or any sponsor of a resolution may call for a vote on that - resolution and all related amendments. - </li> - - <li>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).</li> - - <li> - 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. - </li> -</ol> - -<h3>A.3. Voting procedure</h3> - -<ol> - <li> - 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). - </li> - - <li> - The default option must not have any supermajority requirements. - Options which do not have an explicit supermajority requirement - have a 1:1 majority requirement. - </li> - - <li> - The votes are counted according to the rules in A.6. The - default option is <q>Further Discussion</q>, unless specified - otherwise. - </li> - - <li>In cases of doubt the Project Secretary shall decide on matters - of procedure.</li> -</ol> - -<h3>A.4. Withdrawing resolutions or unaccepted amendments</h3> - -<p>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.</p> - -<p>A sponsor of a resolution or amendment (unless it has been -accepted) may withdraw.</p> - -<p>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.</p> - -<h3>A.5. Expiry</h3> - -<p> - 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. -</p> - -<p> - The secretary may also include suggestions on how to proceed, - if appropriate. -</p> - -<h3>A.6. Vote Counting</h3> - -<ol> - <li> 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. - </li> - <li> 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. - </li> - <li> Any (non-default) option which does not defeat the default option - by its required majority ratio is dropped from consideration. - <ol> - <li> - Given two options A and B, V(A,B) is the number of voters - who prefer option A over option B. - </li> - <li> - 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). - </li> - <li> - If a supermajority of S:1 is required for A, its majority ratio - is S; otherwise, its majority ratio is 1. - </li> - </ol> - </li> - <li> From the list of undropped options, we generate a list of - pairwise defeats. - <ol> - <li> - An option A defeats an option B, if V(A,B) is strictly greater - than V(B,A). - </li> - </ol> - </li> - <li> From the list of [undropped] pairwise defeats, we generate a - set of transitive defeats. - <ol> - <li> - 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. - </li> - </ol> - </li> - <li> We construct the Schwartz set from the set of transitive defeats. - <ol> - <li> - 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. - </li> - </ol> - </li> - <li> 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. - <ol> - <li> - 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). - </li> - <li> - A weakest defeat is a defeat that has no other defeat weaker - than it. There may be more than one such defeat. - </li> - </ol> - </li> - <li> 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. - </li> -</ol> - -<p> - <strong>Note:</strong> 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. -</p> - -<p><cite>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.</cite></p> - -<h2>B. Use of language and typography</h2> - -<p>The present indicative (<q>is</q>, for example) means that the statement -is a rule in this constitution. <q>May</q> or <q>can</q> indicates that the -person or body has discretion. <q>Should</q> means that it would be -considered a good thing if the sentence were obeyed, but it is not -binding. <cite>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.</cite></p> diff --git a/greek/devel/constitution.1.3.wml b/greek/devel/constitution.1.3.wml deleted file mode 100644 index 3cba8f50e85..00000000000 --- a/greek/devel/constitution.1.3.wml +++ /dev/null @@ -1,976 +0,0 @@ -#use wml::debian::template title="Historical Debian Constitution v 1.3" BARETITLE="true" -#use wml::debian::toc -#use wml::debian::translation-check translation="ba01cfdc529712e3626bdf15fd37d39e94126794" maintainer="galaxico" - -<h1>Historical version of the Constitution for the Debian Project (v1.3)</h1> - -<p>Version 1.3 ratified on September 24th, 2006. Supersedes -<a href="constitution.1.2">Version 1.2</a> ratified on October 29th, -2003 and -<a href="constitution.1.1">Version 1.1</a> ratified on June 21st, -2003, which itself supersedes <a href="constitution.1.0">Version 1.0</a> -ratified on December 2nd, 1998. -Version 1.3 was again superseded by <a href="constitution.1.4">version 1.4</a> -ratified on October 7th, 2007. -That was superseded by the <a href="constitution.1.5">version 1.5</a> -ratified on January 9th, 2015, and again superseeded by the -<a href="constitution.1.6">version 1.6</a>, ratified on December 13th, 2015. -That was superseeded by the <a href="constitution">current version 1.7</a>, -ratified on August 14th, 2016. -</p> - -<toc-display /> - -<toc-add-entry name="item-1">1. Introduction</toc-add-entry> - -<p><cite>The Debian Project is an association of individuals who have -made common cause to create a free operating system.</cite></p> - -<p>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.</p> - -<toc-add-entry name="item-2">2. Decision-making bodies and individuals</toc-add-entry> - -<p>Each decision in the Project is made by one or more of the -following:</p> - -<ol> - <li>The Developers, by way of General Resolution or an election;</li> - - <li>The Project Leader;</li> - - <li>The Technical Committee and/or its Chairman;</li> - - <li>The individual Developer working on a particular task;</li> - - <li>Delegates appointed by the Project Leader for specific - tasks;</li> - - <li>The Project Secretary.</li> -</ol> - -<p>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. <cite>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.</cite></p> - -<h3>2.1. General rules</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>A person may leave the Project or resign from a particular post - they hold, at any time, by stating so publicly.</p> - </li> -</ol> - -<toc-add-entry name="item-3">3. Individual Developers</toc-add-entry> - -<h3>3.1. Powers</h3> - -<p>An individual Developer may</p> - -<ol> - <li>make any technical or nontechnical decision with regard to their - own work;</li> - - <li>propose or sponsor draft General Resolutions;</li> - - <li>propose themselves as a Project Leader candidate in - elections;</li> - - <li>vote on General Resolutions and in Leadership elections.</li> -</ol> - -<h3>3.2. Composition and appointment</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>The Project Leader's Delegate(s) may choose not to admit new - Developers, or expel existing Developers. <cite>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.</cite></p> - </li> -</ol> - -<h3>3.3. Procedure</h3> - -<p>Developers may make these decisions as they see fit.</p> - -<toc-add-entry name="item-4">4. The Developers by way of General Resolution or election</toc-add-entry> - -<h3>4.1. Powers</h3> - -<p>Together, the Developers may:</p> - -<ol> - <li> - <p>Appoint or recall the Project Leader.</p> - </li> - - <li> - <p>Amend this constitution, provided they agree with a 3:1 - majority.</p> - </li> - - <li> - <p>Make or override any decision authorised by the powers of the Project - Leader or a Delegate.</p> - </li> - - <li> - <p>Make or override any decision authorised by the powers of the Technical - Committee, provided they agree with a 2:1 majority.</p> - </li> - - <li> - <p>Issue, supersede and withdraw nontechnical policy documents and - statements.</p> - - <p>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.</p> - - <p>They may also include position statements about issues of the - day.</p> - - <ol style="list-style: decimal;"> - <li>A Foundation Document is a document or statement regarded as - critical to the Project's mission and purposes.</li> - <li>The Foundation Documents are the works entitled <q>Debian - Social Contract</q> and <q>Debian Free Software Guidelines</q>.</li> - <li>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.</li> - </ol> - - </li> - - <li> - <p>Make decisions about property held in trust for purposes - related to Debian. (See §9.).</p> - </li> - - <li> - <p>In case of a disagreement between the project leader and - the incumbent secretary, appoint a new secretary.</p> - </li> -</ol> - -<h3>4.2. Procedure</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>Delaying a decision by the Project Leader or their Delegate:</p> - - <ol> - <li>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 §4.1(3).</li> - - <li>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).</li> - - <li>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.</li> - - <li>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.</li> - - <li>If the Project Leader (or the Delegate) withdraws the - original decision, the vote becomes moot, and is no longer - conducted.</li> - </ol> - </li> - - <li> - <p> - 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. - </p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>Votes are cast by email in a manner suitable to the Secretary. - The Secretary determines for each poll whether voters can change - their votes.</p> - </li> - - <li> - <p>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.</p> - </li> -</ol> - -<toc-add-entry name="item-5">5. Project Leader</toc-add-entry> - -<h3>5.1. Powers</h3> - -<p>The <a href="leader">Project Leader</a> may:</p> - -<ol> - <li> - <p>Appoint Delegates or delegate decisions to the Technical - Committee.</p> - - <p>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.</p> - - <p>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.</p> - </li> - - <li> - <p>Lend authority to other Developers.</p> - - <p>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.</p> - </li> - - <li> - <p>Make any decision which requires urgent action.</p> - - <p>This does not apply to decisions which have only become - gradually urgent through lack of relevant action, unless there is a - fixed deadline.</p> - </li> - - <li> - <p>Make any decision for whom noone else has responsibility.</p> - </li> - - <li> - <p>Propose draft General Resolutions and amendments.</p> - </li> - - <li> - <p>Together with the Technical Committee, appoint new members to - the Committee. (See §6.2.)</p> - </li> - - <li> - <p>Use a casting vote when Developers vote.</p> - - <p>The Project Leader also has a normal vote in such ballots.</p> - </li> - - <li> - <p>Vary the discussion period for Developers' votes (as above).</p> - </li> - - <li> - <p>Lead discussions amongst Developers.</p> - - <p>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.</p> - </li> - - <li> - <p>In consultation with the developers, make decisions affecting - property held in trust for purposes related to Debian. (See - §9.). Such decisions are communicated to the members by the - Project Leader or their Delegate(s). Major expenditures - should be proposed and debated on the mailing list before - funds are disbursed.</p> - </li> - <li> - <p>Add or remove organizations from the list of trusted - organizations (see §9.3) that are authorized to accept and - hold assets for Debian. The evaluation and discussion leading - up to such a decision occurs on an electronic mailing list - designated by the Project Leader or their Delegate(s), on - which any developer may post. There is a minimum discussion - period of two weeks before an organization may be added to - the list of trusted organizations.</p> - </li> -</ol> - -<h3>5.2. Appointment</h3> - -<ol> - <li>The Project Leader is elected by the Developers.</li> - - <li>The election begins nine weeks before the leadership post becomes - vacant, or (if it is too late already) immediately.</li> - - <li>For the following three weeks any Developer may nominate - themselves as a candidate Project Leader.</li> - - <li>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.</li> - - <li>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.</li> - - <li>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.</li> - - <li> - 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 <q>None Of The Above</q>. - </li> - - <li>The Project Leader serves for one year from their election.</li> -</ol> - -<h3>5.3. Procedure</h3> - -<p>The Project Leader should attempt to make decisions which are -consistent with the consensus of the opinions of the Developers.</p> - -<p>Where practical the Project Leader should informally solicit the -views of the Developers.</p> - -<p>The Project Leader should avoid overemphasizing their own point of -view when making decisions in their capacity as Leader.</p> - -<toc-add-entry name="item-6">6. Technical committee</toc-add-entry> - -<h3>6.1. Powers</h3> - -<p>The <a href="tech-ctte">Technical Committee</a> may:</p> - -<ol> - <li> - <p>Decide on any matter of technical policy.</p> - - <p>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).)</p> - </li> - - <li> - <p>Decide any technical matter where Developers' jurisdictions - overlap.</p> - - <p>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.</p> - </li> - - <li> - <p>Make a decision when asked to do so.</p> - - <p>Any person or body may delegate a decision of their own to the - Technical Committee, or seek advice from it.</p> - </li> - - <li> - <p>Overrule a Developer (requires a 3:1 majority).</p> - - <p>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.</p> - </li> - - <li> - <p>Offer advice.</p> - - <p>The Technical Committee may make formal announcements about its - views on any matter. <cite>Individual members may of course make - informal statements about their views and about the likely views of - the committee.</cite></p> - </li> - - <li> - <p>Together with the Project Leader, appoint new members to itself - or remove existing members. (See §6.2.)</p> - </li> - - <li> - <p>Appoint the Chairman of the Technical Committee.</p> - - <p> - 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. - </p> - </li> - - <li> - <p>The Chairman can stand in for the Leader, together with the - Secretary</p> - - <p>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.</p> - </li> -</ol> - -<h3>6.2. Composition</h3> - -<ol> - <li> - <p>The Technical Committee consists of up to 8 Developers, and - should usually have at least 4 members.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>When there are 5 members or fewer the Technical Committee may - appoint new member(s) until the number of members reaches 6.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>If the Technical Committee and the Project Leader agree they - may remove or replace an existing member of the Technical - Committee.</p> - </li> -</ol> - -<h3>6.3. Procedure</h3> - -<ol> - <li> - <p>The Technical Committee uses the Standard Resolution - Procedure.</p> - - <p>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.</p> - </li> - - <li> - <p>Details regarding voting</p> - - <p>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).</p> - </li> - - <li> - <p>Public discussion and decision-making.</p> - - <p>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.</p> - </li> - - <li> - <p>Confidentiality of appointments.</p> - - <p>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.</p> - </li> - - <li> - <p>No detailed design work.</p> - - <p>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.</p> - - <p>The Technical Committee restricts itself to choosing from or - adopting compromises between solutions and decisions which have - been proposed and reasonably thoroughly discussed elsewhere.</p> - - <p><cite>Individual members of the technical committee may of - course participate on their own behalf in any aspect of design and - policy work.</cite></p> - </li> - - <li> - <p>Technical Committee makes decisions only as last resort.</p> - - <p>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.</p> - </li> -</ol> - -<toc-add-entry name="item-7">7. The Project Secretary</toc-add-entry> - -<h3>7.1. Powers</h3> - -<p>The <a href="secretary">Secretary</a>:</p> - -<ol> - <li> - <p>Takes votes amongst the Developers, and determines the number - and identity of Developers, whenever this is required by the - constitution.</p> - </li> - - <li> - <p>Can stand in for the Leader, together with the Chairman of the - Technical Committee.</p> - - <p>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.</p> - </li> - - <li> - <p>Adjudicates any disputes about interpretation of the - constitution.</p> - </li> - - <li> - <p>May delegate part or all of their authority to someone else, or - withdraw such a delegation at any time.</p> - </li> -</ol> - -<h3>7.2. Appointment</h3> - -<p>The Project Secretary is appointed by the Project Leader and the -current Project Secretary.</p> - -<p>If the Project Leader and the current Project Secretary cannot agree -on a new appointment, they must ask the Developers by way of -General Resolution to appoint a Secretary.</p> - -<p>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.</p> - -<p>The Project Secretary's term of office is 1 year, at which point -they or another Secretary must be (re)appointed.</p> - -<h3>7.3. Procedure</h3> - -<p>The Project Secretary should make decisions which are fair and -reasonable, and preferably consistent with the consensus of the -Developers.</p> - -<p>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.</p> - -<toc-add-entry name="item-8">8. The Project Leader's Delegates</toc-add-entry> - -<h3>8.1. Powers</h3> - -<p>The Project Leader's Delegates:</p> - -<ol> - <li>have powers delegated to them by the Project Leader;</li> - - <li>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. <cite>This is to - avoid concentration of power, particularly over membership as a - Developer, in the hands of the Project Leader.</cite></li> -</ol> - -<h3>8.2. Appointment</h3> - -<p>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.</p> - -<h3>8.3. Procedure</h3> - -<p>Delegates may make decisions as they see fit, but should attempt to -implement good technical decisions and/or follow consensus opinion.</p> - -<toc-add-entry name="item-9">9. Assets held in trust for Debian</toc-add-entry> - -<p>In most jurisdictions around the world, the Debian project is not -in a position to directly hold funds or other property. Therefore, -property has to be owned by any of a number of organisations as -detailed in §9.2.</p> - -<p>Traditionally, SPI was the sole organisation authorized to hold -property and monies for the Debian Project. SPI was created in -the U.S. to hold money in trust there.</p> - -<p><a href="https://www.spi-inc.org/">SPI</a> and Debian are separate -organisations who share some goals. -Debian is grateful for the legal support framework offered by SPI.</p> - -<h3>9.1. Relationship with Associated Organizations</h3> - -<ol> - <li> - <p>Debian Developers do not become agents or employees of - organisations holding assets in trust for Debian, or of - each other, or of persons in authority in the Debian Project, - solely by the virtue of being Debian Developers. A person - acting as a Developer does so as an individual, on their own - behalf. Such organisations may, of their own accord, - establish relationships with individuals who are also Debian - developers.</p> - </li> -</ol> - -<h3>9.2. Authority</h3> - -<ol> - <li> - <p>An organisation holding assets for Debian has no authority - regarding Debian's technical or nontechnical decisions, except - that no decision by Debian with respect to any property held - by the organisation shall require it to act outside its legal - authority.</p> - </li> - <li> - <p>Debian claims no authority over an organisation that holds - assets for Debian other than that over the use of property - held in trust for Debian.</p> - </li> -</ol> - -<h3>9.3. Trusted organisations</h3> - -<p>Any donations for the Debian Project must be made to any one of a -set of organisations designated by the Project leader (or a -delegate) to be authorized to handle assets to be used for the -Debian Project.</p> - -<p>Organisations holding assets in trust for Debian should -undertake reasonable obligations for the handling of such -assets.</p> - -<p>Debian maintains a public List of Trusted Organisations that -accept donations and hold assets in trust for Debian -(including both tangible property and intellectual property) -that includes the commitments those organisations have made as -to how those assets will be handled.</p> - -<toc-add-entry name="item-A">A. Standard Resolution Procedure</toc-add-entry> - -<p>These rules apply to communal decision-making by committees and -plebiscites, where stated above.</p> - -<h3>A.1. Proposal</h3> - -<p>The formal procedure begins when a draft resolution is proposed and -sponsored, as required.</p> - -<h3>A.1. Discussion and Amendment</h3> - -<ol> - <li>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.</li> - - <li>A formal amendment may be accepted by the resolution's proposer, - in which case the formal resolution draft is immediately changed to - match.</li> - - <li>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.</li> - - <li>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).)</li> - - <li>The proposer of a resolution may suggest changes to the wordings - of amendments; these take effect if the proposer of the amendment - agrees and none of the sponsors object. In this case the changed - amendments will be voted on instead of the originals.</li> - - <li>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.</li> -</ol> - -<h3>A.2. Calling for a vote</h3> - -<ol> - <li>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.</li> - - <li> - The proposer or any sponsor of a resolution may call for a vote on that - resolution and all related amendments. - </li> - - <li>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).</li> - - <li> - 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. - </li> -</ol> - -<h3>A.3. Voting procedure</h3> - -<ol> - <li> - 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). - </li> - - <li> - The default option must not have any supermajority requirements. - Options which do not have an explicit supermajority requirement - have a 1:1 majority requirement. - </li> - - <li> - The votes are counted according to the rules in A.6. The - default option is <q>Further Discussion</q>, unless specified - otherwise. - </li> - - <li>In cases of doubt the Project Secretary shall decide on matters - of procedure.</li> -</ol> - -<h3>A.4. Withdrawing resolutions or unaccepted amendments</h3> - -<p>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.</p> - -<p>A sponsor of a resolution or amendment (unless it has been -accepted) may withdraw.</p> - -<p>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.</p> - -<h3>A.5. Expiry</h3> - -<p> - 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. -</p> - -<p> - The secretary may also include suggestions on how to proceed, - if appropriate. -</p> - -<h3>A.6. Vote Counting</h3> - -<ol> - <li> 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. - </li> - <li> 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. - </li> - <li> Any (non-default) option which does not defeat the default option - by its required majority ratio is dropped from consideration. - <ol> - <li> - Given two options A and B, V(A,B) is the number of voters - who prefer option A over option B. - </li> - <li> - 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). - </li> - <li> - If a supermajority of S:1 is required for A, its majority ratio - is S; otherwise, its majority ratio is 1. - </li> - </ol> - </li> - <li> From the list of undropped options, we generate a list of - pairwise defeats. - <ol> - <li> - An option A defeats an option B, if V(A,B) is strictly greater - than V(B,A). - </li> - </ol> - </li> - <li> From the list of [undropped] pairwise defeats, we generate a - set of transitive defeats. - <ol> - <li> - 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. - </li> - </ol> - </li> - <li> We construct the Schwartz set from the set of transitive defeats. - <ol> - <li> - 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. - </li> - </ol> - </li> - <li> 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. - <ol> - <li> - 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). - </li> - <li> - A weakest defeat is a defeat that has no other defeat weaker - than it. There may be more than one such defeat. - </li> - </ol> - </li> - <li> 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. - </li> -</ol> - -<p> - <strong>Note:</strong> 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. -</p> - -<p><cite>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.</cite></p> - -<toc-add-entry name="item-B">B. Use of language and typography</toc-add-entry> - -<p>The present indicative (<q>is</q>, for example) means that the statement -is a rule in this constitution. <q>May</q> or <q>can</q> indicates that the -person or body has discretion. <q>Should</q> means that it would be -considered a good thing if the sentence were obeyed, but it is not -binding. <cite>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.</cite></p> diff --git a/greek/devel/constitution.1.4.wml b/greek/devel/constitution.1.4.wml deleted file mode 100644 index b40db870956..00000000000 --- a/greek/devel/constitution.1.4.wml +++ /dev/null @@ -1,976 +0,0 @@ -#use wml::debian::template title="Historical Debian Constitution v 1.4" BARETITLE="true" -#use wml::debian::toc -#use wml::debian::translation-check translation="ba01cfdc529712e3626bdf15fd37d39e94126794" maintainer="galaxico" - -<h1>Historical version of the Constitution for the Debian Project (v1.4)</h1> - -<p>Version 1.4 ratified on October 7th, 2007. Supersedes -<a href="constitution.1.3">Version 1.3</a> ratified on September 24th, -2006, -<a href="constitution.1.2">Version 1.2</a> ratified on October 29th, -2003 and -<a href="constitution.1.1">Version 1.1</a> ratified on June 21st, -2003, which itself supersedes <a href="constitution.1.0">Version 1.0</a> -ratified on December 2nd, 1998. -That was superseded by the <a href="constitution.1.5">version 1.5</a> -ratified on January 9th, 2015, and again superseded by the -<a href="constitution.1.6">version 1.6</a>, ratified on December 13th, 2015. -That was superseded by the <a href="constitution">current version 1.7</a>, -ratified on August 14th, 2016. -</p> - -<toc-display /> - -<toc-add-entry name="item-1">1. Introduction</toc-add-entry> - -<p><cite>The Debian Project is an association of individuals who have -made common cause to create a free operating system.</cite></p> - -<p>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.</p> - -<toc-add-entry name="item-2">2. Decision-making bodies and individuals</toc-add-entry> - -<p>Each decision in the Project is made by one or more of the -following:</p> - -<ol> - <li>The Developers, by way of General Resolution or an election;</li> - - <li>The Project Leader;</li> - - <li>The Technical Committee and/or its Chairman;</li> - - <li>The individual Developer working on a particular task;</li> - - <li>Delegates appointed by the Project Leader for specific - tasks;</li> - - <li>The Project Secretary.</li> -</ol> - -<p>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. <cite>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.</cite></p> - -<h3>2.1. General rules</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>A person may leave the Project or resign from a particular post - they hold, at any time, by stating so publicly.</p> - </li> -</ol> - -<toc-add-entry name="item-3">3. Individual Developers</toc-add-entry> - -<h3>3.1. Powers</h3> - -<p>An individual Developer may</p> - -<ol> - <li>make any technical or nontechnical decision with regard to their - own work;</li> - - <li>propose or sponsor draft General Resolutions;</li> - - <li>propose themselves as a Project Leader candidate in - elections;</li> - - <li>vote on General Resolutions and in Leadership elections.</li> -</ol> - -<h3>3.2. Composition and appointment</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>The Project Leader's Delegate(s) may choose not to admit new - Developers, or expel existing Developers. <cite>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.</cite></p> - </li> -</ol> - -<h3>3.3. Procedure</h3> - -<p>Developers may make these decisions as they see fit.</p> - -<toc-add-entry name="item-4">4. The Developers by way of General Resolution or election</toc-add-entry> - -<h3>4.1. Powers</h3> - -<p>Together, the Developers may:</p> - -<ol> - <li> - <p>Appoint or recall the Project Leader.</p> - </li> - - <li> - <p>Amend this constitution, provided they agree with a 3:1 - majority.</p> - </li> - - <li> - <p>Make or override any decision authorised by the powers of the Project - Leader or a Delegate.</p> - </li> - - <li> - <p>Make or override any decision authorised by the powers of the Technical - Committee, provided they agree with a 2:1 majority.</p> - </li> - - <li> - <p>Issue, supersede and withdraw nontechnical policy documents and - statements.</p> - - <p>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.</p> - - <p>They may also include position statements about issues of the - day.</p> - - <ol style="list-style: decimal;"> - <li>A Foundation Document is a document or statement regarded as - critical to the Project's mission and purposes.</li> - <li>The Foundation Documents are the works entitled <q>Debian - Social Contract</q> and <q>Debian Free Software Guidelines</q>.</li> - <li>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.</li> - </ol> - - </li> - - <li> - <p>Make decisions about property held in trust for purposes - related to Debian. (See §9.).</p> - </li> - - <li> - <p>In case of a disagreement between the project leader and - the incumbent secretary, appoint a new secretary.</p> - </li> -</ol> - -<h3>4.2. Procedure</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>Delaying a decision by the Project Leader or their Delegate:</p> - - <ol> - <li>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 §4.1(3).</li> - - <li>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).</li> - - <li>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.</li> - - <li>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.</li> - - <li>If the Project Leader (or the Delegate) withdraws the - original decision, the vote becomes moot, and is no longer - conducted.</li> - </ol> - </li> - - <li> - <p> - 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. - </p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>Votes are cast by email in a manner suitable to the Secretary. - The Secretary determines for each poll whether voters can change - their votes.</p> - </li> - - <li> - <p>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.</p> - </li> -</ol> - -<toc-add-entry name="item-5">5. Project Leader</toc-add-entry> - -<h3>5.1. Powers</h3> - -<p>The <a href="leader">Project Leader</a> may:</p> - -<ol> - <li> - <p>Appoint Delegates or delegate decisions to the Technical - Committee.</p> - - <p>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.</p> - - <p>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.</p> - </li> - - <li> - <p>Lend authority to other Developers.</p> - - <p>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.</p> - </li> - - <li> - <p>Make any decision which requires urgent action.</p> - - <p>This does not apply to decisions which have only become - gradually urgent through lack of relevant action, unless there is a - fixed deadline.</p> - </li> - - <li> - <p>Make any decision for whom noone else has responsibility.</p> - </li> - - <li> - <p>Propose draft General Resolutions and amendments.</p> - </li> - - <li> - <p>Together with the Technical Committee, appoint new members to - the Committee. (See §6.2.)</p> - </li> - - <li> - <p>Use a casting vote when Developers vote.</p> - - <p>The Project Leader also has a normal vote in such ballots.</p> - </li> - - <li> - <p>Vary the discussion period for Developers' votes (as above).</p> - </li> - - <li> - <p>Lead discussions amongst Developers.</p> - - <p>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.</p> - </li> - - <li> - <p>In consultation with the developers, make decisions affecting - property held in trust for purposes related to Debian. (See - §9.). Such decisions are communicated to the members by the - Project Leader or their Delegate(s). Major expenditures - should be proposed and debated on the mailing list before - funds are disbursed.</p> - </li> - <li> - <p>Add or remove organizations from the list of trusted - organizations (see §9.3) that are authorized to accept and - hold assets for Debian. The evaluation and discussion leading - up to such a decision occurs on an electronic mailing list - designated by the Project Leader or their Delegate(s), on - which any developer may post. There is a minimum discussion - period of two weeks before an organization may be added to - the list of trusted organizations.</p> - </li> -</ol> - -<h3>5.2. Appointment</h3> - -<ol> - <li>The Project Leader is elected by the Developers.</li> - - <li>The election begins six weeks before the leadership post becomes - vacant, or (if it is too late already) immediately.</li> - - <li>For the first week any Developer may nominate - themselves as a candidate Project Leader, and summarize their plans for their term.</li> - - <li>For three weeks after that no more candidates may be nominated; - candidates should use this time for campaigning and discussion. If - there are no candidates at the end of the nomination period then the - nomination period is extended for an additional week, repeatedly if - necessary.</li> - - <li>The next two 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.</li> - - <li>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.</li> - - <li> - 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 <q>None Of The Above</q>. - </li> - - <li>The Project Leader serves for one year from their election.</li> -</ol> - -<h3>5.3. Procedure</h3> - -<p>The Project Leader should attempt to make decisions which are -consistent with the consensus of the opinions of the Developers.</p> - -<p>Where practical the Project Leader should informally solicit the -views of the Developers.</p> - -<p>The Project Leader should avoid overemphasizing their own point of -view when making decisions in their capacity as Leader.</p> - -<toc-add-entry name="item-6">6. Technical committee</toc-add-entry> - -<h3>6.1. Powers</h3> - -<p>The <a href="tech-ctte">Technical Committee</a> may:</p> - -<ol> - <li> - <p>Decide on any matter of technical policy.</p> - - <p>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).)</p> - </li> - - <li> - <p>Decide any technical matter where Developers' jurisdictions - overlap.</p> - - <p>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.</p> - </li> - - <li> - <p>Make a decision when asked to do so.</p> - - <p>Any person or body may delegate a decision of their own to the - Technical Committee, or seek advice from it.</p> - </li> - - <li> - <p>Overrule a Developer (requires a 3:1 majority).</p> - - <p>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.</p> - </li> - - <li> - <p>Offer advice.</p> - - <p>The Technical Committee may make formal announcements about its - views on any matter. <cite>Individual members may of course make - informal statements about their views and about the likely views of - the committee.</cite></p> - </li> - - <li> - <p>Together with the Project Leader, appoint new members to itself - or remove existing members. (See §6.2.)</p> - </li> - - <li> - <p>Appoint the Chairman of the Technical Committee.</p> - - <p> - 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. - </p> - </li> - - <li> - <p>The Chairman can stand in for the Leader, together with the - Secretary</p> - - <p>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.</p> - </li> -</ol> - -<h3>6.2. Composition</h3> - -<ol> - <li> - <p>The Technical Committee consists of up to 8 Developers, and - should usually have at least 4 members.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>When there are 5 members or fewer the Technical Committee may - appoint new member(s) until the number of members reaches 6.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>If the Technical Committee and the Project Leader agree they - may remove or replace an existing member of the Technical - Committee.</p> - </li> -</ol> - -<h3>6.3. Procedure</h3> - -<ol> - <li> - <p>The Technical Committee uses the Standard Resolution - Procedure.</p> - - <p>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.</p> - </li> - - <li> - <p>Details regarding voting</p> - - <p>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).</p> - </li> - - <li> - <p>Public discussion and decision-making.</p> - - <p>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.</p> - </li> - - <li> - <p>Confidentiality of appointments.</p> - - <p>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.</p> - </li> - - <li> - <p>No detailed design work.</p> - - <p>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.</p> - - <p>The Technical Committee restricts itself to choosing from or - adopting compromises between solutions and decisions which have - been proposed and reasonably thoroughly discussed elsewhere.</p> - - <p><cite>Individual members of the technical committee may of - course participate on their own behalf in any aspect of design and - policy work.</cite></p> - </li> - - <li> - <p>Technical Committee makes decisions only as last resort.</p> - - <p>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.</p> - </li> -</ol> - -<toc-add-entry name="item-7">7. The Project Secretary</toc-add-entry> - -<h3>7.1. Powers</h3> - -<p>The <a href="secretary">Secretary</a>:</p> - -<ol> - <li> - <p>Takes votes amongst the Developers, and determines the number - and identity of Developers, whenever this is required by the - constitution.</p> - </li> - - <li> - <p>Can stand in for the Leader, together with the Chairman of the - Technical Committee.</p> - - <p>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.</p> - </li> - - <li> - <p>Adjudicates any disputes about interpretation of the - constitution.</p> - </li> - - <li> - <p>May delegate part or all of their authority to someone else, or - withdraw such a delegation at any time.</p> - </li> -</ol> - -<h3>7.2. Appointment</h3> - -<p>The Project Secretary is appointed by the Project Leader and the -current Project Secretary.</p> - -<p>If the Project Leader and the current Project Secretary cannot agree -on a new appointment, they must ask the Developers by way of -General Resolution to appoint a Secretary.</p> - -<p>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.</p> - -<p>The Project Secretary's term of office is 1 year, at which point -they or another Secretary must be (re)appointed.</p> - -<h3>7.3. Procedure</h3> - -<p>The Project Secretary should make decisions which are fair and -reasonable, and preferably consistent with the consensus of the -Developers.</p> - -<p>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.</p> - -<toc-add-entry name="item-8">8. The Project Leader's Delegates</toc-add-entry> - -<h3>8.1. Powers</h3> - -<p>The Project Leader's Delegates:</p> - -<ol> - <li>have powers delegated to them by the Project Leader;</li> - - <li>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. <cite>This is to - avoid concentration of power, particularly over membership as a - Developer, in the hands of the Project Leader.</cite></li> -</ol> - -<h3>8.2. Appointment</h3> - -<p>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.</p> - -<h3>8.3. Procedure</h3> - -<p>Delegates may make decisions as they see fit, but should attempt to -implement good technical decisions and/or follow consensus opinion.</p> - -<toc-add-entry name="item-9">9. Assets held in trust for Debian</toc-add-entry> - -<p>In most jurisdictions around the world, the Debian project is not -in a position to directly hold funds or other property. Therefore, -property has to be owned by any of a number of organisations as -detailed in §9.2.</p> - -<p>Traditionally, SPI was the sole organisation authorized to hold -property and monies for the Debian Project. SPI was created in -the U.S. to hold money in trust there.</p> - -<p><a href="https://www.spi-inc.org/">SPI</a> and Debian are separate -organisations who share some goals. -Debian is grateful for the legal support framework offered by SPI.</p> - -<h3>9.1. Relationship with Associated Organizations</h3> - -<ol> - <li> - <p>Debian Developers do not become agents or employees of - organisations holding assets in trust for Debian, or of - each other, or of persons in authority in the Debian Project, - solely by the virtue of being Debian Developers. A person - acting as a Developer does so as an individual, on their own - behalf. Such organisations may, of their own accord, - establish relationships with individuals who are also Debian - developers.</p> - </li> -</ol> - -<h3>9.2. Authority</h3> - -<ol> - <li> - <p>An organisation holding assets for Debian has no authority - regarding Debian's technical or nontechnical decisions, except - that no decision by Debian with respect to any property held - by the organisation shall require it to act outside its legal - authority.</p> - </li> - <li> - <p>Debian claims no authority over an organisation that holds - assets for Debian other than that over the use of property - held in trust for Debian.</p> - </li> -</ol> - -<h3>9.3. Trusted organisations</h3> - -<p>Any donations for the Debian Project must be made to any one of a -set of organisations designated by the Project leader (or a -delegate) to be authorized to handle assets to be used for the -Debian Project.</p> - -<p>Organisations holding assets in trust for Debian should -undertake reasonable obligations for the handling of such -assets.</p> - -<p>Debian maintains a public List of Trusted Organisations that -accept donations and hold assets in trust for Debian -(including both tangible property and intellectual property) -that includes the commitments those organisations have made as -to how those assets will be handled.</p> - -<toc-add-entry name="item-A">A. Standard Resolution Procedure</toc-add-entry> - -<p>These rules apply to communal decision-making by committees and -plebiscites, where stated above.</p> - -<h3>A.1. Proposal</h3> - -<p>The formal procedure begins when a draft resolution is proposed and -sponsored, as required.</p> - -<h3>A.1. Discussion and Amendment</h3> - -<ol> - <li>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.</li> - - <li>A formal amendment may be accepted by the resolution's proposer, - in which case the formal resolution draft is immediately changed to - match.</li> - - <li>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.</li> - - <li>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).)</li> - - <li>The proposer of a resolution may suggest changes to the wordings - of amendments; these take effect if the proposer of the amendment - agrees and none of the sponsors object. In this case the changed - amendments will be voted on instead of the originals.</li> - - <li>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.</li> -</ol> - -<h3>A.2. Calling for a vote</h3> - -<ol> - <li>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.</li> - - <li> - The proposer or any sponsor of a resolution may call for a vote on that - resolution and all related amendments. - </li> - - <li>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).</li> - - <li> - 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. - </li> -</ol> - -<h3>A.3. Voting procedure</h3> - -<ol> - <li> - 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). - </li> - - <li> - The default option must not have any supermajority requirements. - Options which do not have an explicit supermajority requirement - have a 1:1 majority requirement. - </li> - - <li> - The votes are counted according to the rules in A.6. The - default option is <q>Further Discussion</q>, unless specified - otherwise. - </li> - - <li>In cases of doubt the Project Secretary shall decide on matters - of procedure.</li> -</ol> - -<h3>A.4. Withdrawing resolutions or unaccepted amendments</h3> - -<p>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.</p> - -<p>A sponsor of a resolution or amendment (unless it has been -accepted) may withdraw.</p> - -<p>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.</p> - -<h3>A.5. Expiry</h3> - -<p> - 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. -</p> - -<p> - The secretary may also include suggestions on how to proceed, - if appropriate. -</p> - -<h3>A.6. Vote Counting</h3> - -<ol> - <li> 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. - </li> - <li> 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. - </li> - <li> Any (non-default) option which does not defeat the default option - by its required majority ratio is dropped from consideration. - <ol> - <li> - Given two options A and B, V(A,B) is the number of voters - who prefer option A over option B. - </li> - <li> - 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). - </li> - <li> - If a supermajority of S:1 is required for A, its majority ratio - is S; otherwise, its majority ratio is 1. - </li> - </ol> - </li> - <li> From the list of undropped options, we generate a list of - pairwise defeats. - <ol> - <li> - An option A defeats an option B, if V(A,B) is strictly greater - than V(B,A). - </li> - </ol> - </li> - <li> From the list of [undropped] pairwise defeats, we generate a - set of transitive defeats. - <ol> - <li> - 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. - </li> - </ol> - </li> - <li> We construct the Schwartz set from the set of transitive defeats. - <ol> - <li> - 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. - </li> - </ol> - </li> - <li> 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. - <ol> - <li> - 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). - </li> - <li> - A weakest defeat is a defeat that has no other defeat weaker - than it. There may be more than one such defeat. - </li> - </ol> - </li> - <li> 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. - </li> -</ol> - -<p> - <strong>Note:</strong> 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. -</p> - -<p><cite>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.</cite></p> - -<toc-add-entry name="item-B">B. Use of language and typography</toc-add-entry> - -<p>The present indicative (<q>is</q>, for example) means that the statement -is a rule in this constitution. <q>May</q> or <q>can</q> indicates that the -person or body has discretion. <q>Should</q> means that it would be -considered a good thing if the sentence were obeyed, but it is not -binding. <cite>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.</cite></p> diff --git a/greek/devel/constitution.1.5.wml b/greek/devel/constitution.1.5.wml deleted file mode 100644 index 407a7f9cdde..00000000000 --- a/greek/devel/constitution.1.5.wml +++ /dev/null @@ -1,1002 +0,0 @@ -#use wml::debian::template title="Historical Debian Constitution v 1.5" BARETITLE="true" -#use wml::debian::toc -#use wml::debian::translation-check translation="ba01cfdc529712e3626bdf15fd37d39e94126794" maintainer="galaxico" - -<h1>Historical version of the Constitution for the Debian Project (v1.5)</h1> - -<p>Version 1.5 ratified on January 9th, 2015. Supersedes -<a href="constitution.1.4">Version 1.4</a> ratified on October 7th, 2007, -<a href="constitution.1.3">Version 1.3</a> ratified on September 24th, -2006, -<a href="constitution.1.2">Version 1.2</a> ratified on October 29th, -2003 and -<a href="constitution.1.1">Version 1.1</a> ratified on June 21st, -2003, which itself supersedes <a href="constitution.1.0">Version 1.0</a> -ratified on December 2nd, 1998. -That was superseded by the -<a href="constitution.1.6">version 1.6</a>, ratified on December 13th, 2015. -That was superseded by the <a href="constitution">current version 1.7</a>, -ratified on August 14th, 2016. -</p> - -<toc-display /> - -<toc-add-entry name="item-1">1. Introduction</toc-add-entry> - -<p><cite>The Debian Project is an association of individuals who have -made common cause to create a free operating system.</cite></p> - -<p>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.</p> - -<toc-add-entry name="item-2">2. Decision-making bodies and individuals</toc-add-entry> - -<p>Each decision in the Project is made by one or more of the -following:</p> - -<ol> - <li>The Developers, by way of General Resolution or an election;</li> - - <li>The Project Leader;</li> - - <li>The Technical Committee and/or its Chairman;</li> - - <li>The individual Developer working on a particular task;</li> - - <li>Delegates appointed by the Project Leader for specific - tasks;</li> - - <li>The Project Secretary.</li> -</ol> - -<p>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. <cite>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.</cite></p> - -<h3>2.1. General rules</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>A person may leave the Project or resign from a particular post - they hold, at any time, by stating so publicly.</p> - </li> -</ol> - -<toc-add-entry name="item-3">3. Individual Developers</toc-add-entry> - -<h3>3.1. Powers</h3> - -<p>An individual Developer may</p> - -<ol> - <li>make any technical or nontechnical decision with regard to their - own work;</li> - - <li>propose or sponsor draft General Resolutions;</li> - - <li>propose themselves as a Project Leader candidate in - elections;</li> - - <li>vote on General Resolutions and in Leadership elections.</li> -</ol> - -<h3>3.2. Composition and appointment</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>The Project Leader's Delegate(s) may choose not to admit new - Developers, or expel existing Developers. <cite>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.</cite></p> - </li> -</ol> - -<h3>3.3. Procedure</h3> - -<p>Developers may make these decisions as they see fit.</p> - -<toc-add-entry name="item-4">4. The Developers by way of General Resolution or election</toc-add-entry> - -<h3>4.1. Powers</h3> - -<p>Together, the Developers may:</p> - -<ol> - <li> - <p>Appoint or recall the Project Leader.</p> - </li> - - <li> - <p>Amend this constitution, provided they agree with a 3:1 - majority.</p> - </li> - - <li> - <p>Make or override any decision authorised by the powers of the Project - Leader or a Delegate.</p> - </li> - - <li> - <p>Make or override any decision authorised by the powers of the Technical - Committee, provided they agree with a 2:1 majority.</p> - </li> - - <li> - <p>Issue, supersede and withdraw nontechnical policy documents and - statements.</p> - - <p>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.</p> - - <p>They may also include position statements about issues of the - day.</p> - - <ol style="list-style: decimal;"> - <li>A Foundation Document is a document or statement regarded as - critical to the Project's mission and purposes.</li> - <li>The Foundation Documents are the works entitled <q>Debian - Social Contract</q> and <q>Debian Free Software Guidelines</q>.</li> - <li>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.</li> - </ol> - - </li> - - <li> - <p>Make decisions about property held in trust for purposes - related to Debian. (See §9.).</p> - </li> - - <li> - <p>In case of a disagreement between the project leader and - the incumbent secretary, appoint a new secretary.</p> - </li> -</ol> - -<h3>4.2. Procedure</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>Delaying a decision by the Project Leader or their Delegate:</p> - - <ol> - <li>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 §4.1(3).</li> - - <li>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).</li> - - <li>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.</li> - - <li>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.</li> - - <li>If the Project Leader (or the Delegate) withdraws the - original decision, the vote becomes moot, and is no longer - conducted.</li> - </ol> - </li> - - <li> - <p> - 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. - </p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>Votes are cast by email in a manner suitable to the Secretary. - The Secretary determines for each poll whether voters can change - their votes.</p> - </li> - - <li> - <p>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.</p> - </li> -</ol> - -<toc-add-entry name="item-5">5. Project Leader</toc-add-entry> - -<h3>5.1. Powers</h3> - -<p>The <a href="leader">Project Leader</a> may:</p> - -<ol> - <li> - <p>Appoint Delegates or delegate decisions to the Technical - Committee.</p> - - <p>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.</p> - - <p>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.</p> - </li> - - <li> - <p>Lend authority to other Developers.</p> - - <p>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.</p> - </li> - - <li> - <p>Make any decision which requires urgent action.</p> - - <p>This does not apply to decisions which have only become - gradually urgent through lack of relevant action, unless there is a - fixed deadline.</p> - </li> - - <li> - <p>Make any decision for whom noone else has responsibility.</p> - </li> - - <li> - <p>Propose draft General Resolutions and amendments.</p> - </li> - - <li> - <p>Together with the Technical Committee, appoint new members to - the Committee. (See §6.2.)</p> - </li> - - <li> - <p>Use a casting vote when Developers vote.</p> - - <p>The Project Leader also has a normal vote in such ballots.</p> - </li> - - <li> - <p>Vary the discussion period for Developers' votes (as above).</p> - </li> - - <li> - <p>Lead discussions amongst Developers.</p> - - <p>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.</p> - </li> - - <li> - <p>In consultation with the developers, make decisions affecting - property held in trust for purposes related to Debian. (See - §9.). Such decisions are communicated to the members by the - Project Leader or their Delegate(s). Major expenditures - should be proposed and debated on the mailing list before - funds are disbursed.</p> - </li> - <li> - <p>Add or remove organizations from the list of trusted - organizations (see §9.3) that are authorized to accept and - hold assets for Debian. The evaluation and discussion leading - up to such a decision occurs on an electronic mailing list - designated by the Project Leader or their Delegate(s), on - which any developer may post. There is a minimum discussion - period of two weeks before an organization may be added to - the list of trusted organizations.</p> - </li> -</ol> - -<h3>5.2. Appointment</h3> - -<ol> - <li>The Project Leader is elected by the Developers.</li> - - <li>The election begins six weeks before the leadership post becomes - vacant, or (if it is too late already) immediately.</li> - - <li>For the first week any Developer may nominate - themselves as a candidate Project Leader, and summarize their plans for their term.</li> - - <li>For three weeks after that no more candidates may be nominated; - candidates should use this time for campaigning and discussion. If - there are no candidates at the end of the nomination period then the - nomination period is extended for an additional week, repeatedly if - necessary.</li> - - <li>The next two 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.</li> - - <li>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.</li> - - <li> - 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 <q>None Of The Above</q>. - </li> - - <li>The Project Leader serves for one year from their election.</li> -</ol> - -<h3>5.3. Procedure</h3> - -<p>The Project Leader should attempt to make decisions which are -consistent with the consensus of the opinions of the Developers.</p> - -<p>Where practical the Project Leader should informally solicit the -views of the Developers.</p> - -<p>The Project Leader should avoid overemphasizing their own point of -view when making decisions in their capacity as Leader.</p> - -<toc-add-entry name="item-6">6. Technical committee</toc-add-entry> - -<h3>6.1. Powers</h3> - -<p>The <a href="tech-ctte">Technical Committee</a> may:</p> - -<ol> - <li> - <p>Decide on any matter of technical policy.</p> - - <p>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).)</p> - </li> - - <li> - <p>Decide any technical matter where Developers' jurisdictions - overlap.</p> - - <p>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.</p> - </li> - - <li> - <p>Make a decision when asked to do so.</p> - - <p>Any person or body may delegate a decision of their own to the - Technical Committee, or seek advice from it.</p> - </li> - - <li> - <p>Overrule a Developer (requires a 3:1 majority).</p> - - <p>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.</p> - </li> - - <li> - <p>Offer advice.</p> - - <p>The Technical Committee may make formal announcements about its - views on any matter. <cite>Individual members may of course make - informal statements about their views and about the likely views of - the committee.</cite></p> - </li> - - <li> - <p>Together with the Project Leader, appoint new members to itself - or remove existing members. (See §6.2.)</p> - </li> - - <li> - <p>Appoint the Chairman of the Technical Committee.</p> - - <p> - 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. - </p> - </li> - - <li> - <p>The Chairman can stand in for the Leader, together with the - Secretary</p> - - <p>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.</p> - </li> -</ol> - -<h3>6.2. Composition</h3> - -<ol> - <li> - <p>The Technical Committee consists of up to 8 Developers, and - should usually have at least 4 members.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>When there are 5 members or fewer the Technical Committee may - appoint new member(s) until the number of members reaches 6.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>A Developer is not eligible to be (re)appointed to the Technical - Committee if they have been a member within the previous 12 - months.</p> - </li> - - <li> - <p>If the Technical Committee and the Project Leader agree they - may remove or replace an existing member of the Technical - Committee.</p> - </li> - - <li> - <p>Term limit:</p> - <ol> - <li> - <p>On January 1st of each year the term of any Committee member - who has served more than 42 months (3.5 years) and who is one - of the two most senior members is set to expire on December - 31st of that year.</p> - </li> - <li> - <p>A member of the Technical Committee is said to be more - senior than another if they were appointed earlier, or were - appointed at the same time and have been a member of the - Debian Project longer. In the event that a member has been - appointed more than once, only the most recent appointment is - relevant.</p> - </li> - </ol> - </li> -</ol> - -<h3>6.3. Procedure</h3> - -<ol> - <li> - <p>The Technical Committee uses the Standard Resolution - Procedure.</p> - - <p>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.</p> - </li> - - <li> - <p>Details regarding voting</p> - - <p>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).</p> - </li> - - <li> - <p>Public discussion and decision-making.</p> - - <p>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.</p> - </li> - - <li> - <p>Confidentiality of appointments.</p> - - <p>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.</p> - </li> - - <li> - <p>No detailed design work.</p> - - <p>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.</p> - - <p>The Technical Committee restricts itself to choosing from or - adopting compromises between solutions and decisions which have - been proposed and reasonably thoroughly discussed elsewhere.</p> - - <p><cite>Individual members of the technical committee may of - course participate on their own behalf in any aspect of design and - policy work.</cite></p> - </li> - - <li> - <p>Technical Committee makes decisions only as last resort.</p> - - <p>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.</p> - </li> -</ol> - -<toc-add-entry name="item-7">7. The Project Secretary</toc-add-entry> - -<h3>7.1. Powers</h3> - -<p>The <a href="secretary">Secretary</a>:</p> - -<ol> - <li> - <p>Takes votes amongst the Developers, and determines the number - and identity of Developers, whenever this is required by the - constitution.</p> - </li> - - <li> - <p>Can stand in for the Leader, together with the Chairman of the - Technical Committee.</p> - - <p>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.</p> - </li> - - <li> - <p>Adjudicates any disputes about interpretation of the - constitution.</p> - </li> - - <li> - <p>May delegate part or all of their authority to someone else, or - withdraw such a delegation at any time.</p> - </li> -</ol> - -<h3>7.2. Appointment</h3> - -<p>The Project Secretary is appointed by the Project Leader and the -current Project Secretary.</p> - -<p>If the Project Leader and the current Project Secretary cannot agree -on a new appointment, they must ask the Developers by way of -General Resolution to appoint a Secretary.</p> - -<p>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.</p> - -<p>The Project Secretary's term of office is 1 year, at which point -they or another Secretary must be (re)appointed.</p> - -<h3>7.3. Procedure</h3> - -<p>The Project Secretary should make decisions which are fair and -reasonable, and preferably consistent with the consensus of the -Developers.</p> - -<p>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.</p> - -<toc-add-entry name="item-8">8. The Project Leader's Delegates</toc-add-entry> - -<h3>8.1. Powers</h3> - -<p>The Project Leader's Delegates:</p> - -<ol> - <li>have powers delegated to them by the Project Leader;</li> - - <li>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. <cite>This is to - avoid concentration of power, particularly over membership as a - Developer, in the hands of the Project Leader.</cite></li> -</ol> - -<h3>8.2. Appointment</h3> - -<p>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.</p> - -<h3>8.3. Procedure</h3> - -<p>Delegates may make decisions as they see fit, but should attempt to -implement good technical decisions and/or follow consensus opinion.</p> - -<toc-add-entry name="item-9">9. Assets held in trust for Debian</toc-add-entry> - -<p>In most jurisdictions around the world, the Debian project is not -in a position to directly hold funds or other property. Therefore, -property has to be owned by any of a number of organisations as -detailed in §9.2.</p> - -<p>Traditionally, SPI was the sole organisation authorized to hold -property and monies for the Debian Project. SPI was created in -the U.S. to hold money in trust there.</p> - -<p><a href="https://www.spi-inc.org/">SPI</a> and Debian are separate -organisations who share some goals. -Debian is grateful for the legal support framework offered by SPI.</p> - -<h3>9.1. Relationship with Associated Organizations</h3> - -<ol> - <li> - <p>Debian Developers do not become agents or employees of - organisations holding assets in trust for Debian, or of - each other, or of persons in authority in the Debian Project, - solely by the virtue of being Debian Developers. A person - acting as a Developer does so as an individual, on their own - behalf. Such organisations may, of their own accord, - establish relationships with individuals who are also Debian - developers.</p> - </li> -</ol> - -<h3>9.2. Authority</h3> - -<ol> - <li> - <p>An organisation holding assets for Debian has no authority - regarding Debian's technical or nontechnical decisions, except - that no decision by Debian with respect to any property held - by the organisation shall require it to act outside its legal - authority.</p> - </li> - <li> - <p>Debian claims no authority over an organisation that holds - assets for Debian other than that over the use of property - held in trust for Debian.</p> - </li> -</ol> - -<h3>9.3. Trusted organisations</h3> - -<p>Any donations for the Debian Project must be made to any one of a -set of organisations designated by the Project leader (or a -delegate) to be authorized to handle assets to be used for the -Debian Project.</p> - -<p>Organisations holding assets in trust for Debian should -undertake reasonable obligations for the handling of such -assets.</p> - -<p>Debian maintains a public List of Trusted Organisations that -accept donations and hold assets in trust for Debian -(including both tangible property and intellectual property) -that includes the commitments those organisations have made as -to how those assets will be handled.</p> - -<toc-add-entry name="item-A">A. Standard Resolution Procedure</toc-add-entry> - -<p>These rules apply to communal decision-making by committees and -plebiscites, where stated above.</p> - -<h3>A.1. Proposal</h3> - -<p>The formal procedure begins when a draft resolution is proposed and -sponsored, as required.</p> - -<h3>A.1. Discussion and Amendment</h3> - -<ol> - <li>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.</li> - - <li>A formal amendment may be accepted by the resolution's proposer, - in which case the formal resolution draft is immediately changed to - match.</li> - - <li>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.</li> - - <li>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).)</li> - - <li>The proposer of a resolution may suggest changes to the wordings - of amendments; these take effect if the proposer of the amendment - agrees and none of the sponsors object. In this case the changed - amendments will be voted on instead of the originals.</li> - - <li>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.</li> -</ol> - -<h3>A.2. Calling for a vote</h3> - -<ol> - <li>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.</li> - - <li> - The proposer or any sponsor of a resolution may call for a vote on that - resolution and all related amendments. - </li> - - <li>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).</li> - - <li> - 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. - </li> -</ol> - -<h3>A.3. Voting procedure</h3> - -<ol> - <li> - 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). - </li> - - <li> - The default option must not have any supermajority requirements. - Options which do not have an explicit supermajority requirement - have a 1:1 majority requirement. - </li> - - <li> - The votes are counted according to the rules in A.6. The - default option is <q>Further Discussion</q>, unless specified - otherwise. - </li> - - <li>In cases of doubt the Project Secretary shall decide on matters - of procedure.</li> -</ol> - -<h3>A.4. Withdrawing resolutions or unaccepted amendments</h3> - -<p>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.</p> - -<p>A sponsor of a resolution or amendment (unless it has been -accepted) may withdraw.</p> - -<p>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.</p> - -<h3>A.5. Expiry</h3> - -<p> - 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. -</p> - -<p> - The secretary may also include suggestions on how to proceed, - if appropriate. -</p> - -<h3>A.6. Vote Counting</h3> - -<ol> - <li> 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. - </li> - <li> 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. - </li> - <li> Any (non-default) option which does not defeat the default option - by its required majority ratio is dropped from consideration. - <ol> - <li> - Given two options A and B, V(A,B) is the number of voters - who prefer option A over option B. - </li> - <li> - 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). - </li> - <li> - If a supermajority of S:1 is required for A, its majority ratio - is S; otherwise, its majority ratio is 1. - </li> - </ol> - </li> - <li> From the list of undropped options, we generate a list of - pairwise defeats. - <ol> - <li> - An option A defeats an option B, if V(A,B) is strictly greater - than V(B,A). - </li> - </ol> - </li> - <li> From the list of [undropped] pairwise defeats, we generate a - set of transitive defeats. - <ol> - <li> - 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. - </li> - </ol> - </li> - <li> We construct the Schwartz set from the set of transitive defeats. - <ol> - <li> - 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. - </li> - </ol> - </li> - <li> 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. - <ol> - <li> - 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). - </li> - <li> - A weakest defeat is a defeat that has no other defeat weaker - than it. There may be more than one such defeat. - </li> - </ol> - </li> - <li> 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. - </li> -</ol> - -<p> - <strong>Note:</strong> 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. -</p> - -<p><cite>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.</cite></p> - -<toc-add-entry name="item-B">B. Use of language and typography</toc-add-entry> - -<p>The present indicative (<q>is</q>, for example) means that the statement -is a rule in this constitution. <q>May</q> or <q>can</q> indicates that the -person or body has discretion. <q>Should</q> means that it would be -considered a good thing if the sentence were obeyed, but it is not -binding. <cite>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.</cite></p> diff --git a/greek/devel/constitution.1.6.wml b/greek/devel/constitution.1.6.wml deleted file mode 100644 index 8c5bcc9f9e4..00000000000 --- a/greek/devel/constitution.1.6.wml +++ /dev/null @@ -1,1001 +0,0 @@ -#use wml::debian::template title="Historical Debian Constitution v 1.6" BARETITLE="true" -#use wml::debian::toc -#use wml::debian::translation-check translation="e3d525d9f092f9014e00417cc847900ac5a99649" maintainer="galaxico" - -<h1>Historical version of the Constitution for the Debian Project (v1.6)</h1> - -<p>Version 1.6 ratified on December 13th, 2015. Supersedes -<a href="constitution.1.5">Version 1.5</a> ratified on January 9th, 2015, -<a href="constitution.1.4">Version 1.4</a> ratified on October 7th, 2007, -<a href="constitution.1.3">Version 1.3</a> ratified on September 24th, -2006, -<a href="constitution.1.2">Version 1.2</a> ratified on October 29th, -2003 and -<a href="constitution.1.1">Version 1.1</a> ratified on June 21st, -2003, which itself supersedes <a href="constitution.1.0">Version 1.0</a> -ratified on December 2nd, 1998. -Superseded by the <a href="constitution">current version 1.7</a>, -ratified on August 14th, 2016. -</p> - -<toc-display /> - -<toc-add-entry name="item-1">1. Introduction</toc-add-entry> - -<p><cite>The Debian Project is an association of individuals who have -made common cause to create a free operating system.</cite></p> - -<p>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.</p> - -<toc-add-entry name="item-2">2. Decision-making bodies and individuals</toc-add-entry> - -<p>Each decision in the Project is made by one or more of the -following:</p> - -<ol> - <li>The Developers, by way of General Resolution or an election;</li> - - <li>The Project Leader;</li> - - <li>The Technical Committee and/or its Chairman;</li> - - <li>The individual Developer working on a particular task;</li> - - <li>Delegates appointed by the Project Leader for specific - tasks;</li> - - <li>The Project Secretary.</li> -</ol> - -<p>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. <cite>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.</cite></p> - -<h3>2.1. General rules</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>A person may leave the Project or resign from a particular post - they hold, at any time, by stating so publicly.</p> - </li> -</ol> - -<toc-add-entry name="item-3">3. Individual Developers</toc-add-entry> - -<h3>3.1. Powers</h3> - -<p>An individual Developer may</p> - -<ol> - <li>make any technical or nontechnical decision with regard to their - own work;</li> - - <li>propose or sponsor draft General Resolutions;</li> - - <li>propose themselves as a Project Leader candidate in - elections;</li> - - <li>vote on General Resolutions and in Leadership elections.</li> -</ol> - -<h3>3.2. Composition and appointment</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>The Project Leader's Delegate(s) may choose not to admit new - Developers, or expel existing Developers. <cite>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.</cite></p> - </li> -</ol> - -<h3>3.3. Procedure</h3> - -<p>Developers may make these decisions as they see fit.</p> - -<toc-add-entry name="item-4">4. The Developers by way of General Resolution or election</toc-add-entry> - -<h3>4.1. Powers</h3> - -<p>Together, the Developers may:</p> - -<ol> - <li> - <p>Appoint or recall the Project Leader.</p> - </li> - - <li> - <p>Amend this constitution, provided they agree with a 3:1 - majority.</p> - </li> - - <li> - <p>Make or override any decision authorised by the powers of the Project - Leader or a Delegate.</p> - </li> - - <li> - <p>Make or override any decision authorised by the powers of the Technical - Committee, provided they agree with a 2:1 majority.</p> - </li> - - <li> - <p>Issue, supersede and withdraw nontechnical policy documents and - statements.</p> - - <p>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.</p> - - <p>They may also include position statements about issues of the - day.</p> - - <ol style="list-style: decimal;"> - <li>A Foundation Document is a document or statement regarded as - critical to the Project's mission and purposes.</li> - <li>The Foundation Documents are the works entitled <q>Debian - Social Contract</q> and <q>Debian Free Software Guidelines</q>.</li> - <li>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.</li> - </ol> - - </li> - - <li> - <p>Make decisions about property held in trust for purposes - related to Debian. (See §9.).</p> - </li> - - <li> - <p>In case of a disagreement between the project leader and - the incumbent secretary, appoint a new secretary.</p> - </li> -</ol> - -<h3>4.2. Procedure</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>Delaying a decision by the Project Leader or their Delegate:</p> - - <ol> - <li>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 §4.1(3).</li> - - <li>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).</li> - - <li>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.</li> - - <li>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.</li> - - <li>If the Project Leader (or the Delegate) withdraws the - original decision, the vote becomes moot, and is no longer - conducted.</li> - </ol> - </li> - - <li> - <p> - 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. - </p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>Votes are cast by email in a manner suitable to the Secretary. - The Secretary determines for each poll whether voters can change - their votes.</p> - </li> - - <li> - <p>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.</p> - </li> -</ol> - -<toc-add-entry name="item-5">5. Project Leader</toc-add-entry> - -<h3>5.1. Powers</h3> - -<p>The <a href="leader">Project Leader</a> may:</p> - -<ol> - <li> - <p>Appoint Delegates or delegate decisions to the Technical - Committee.</p> - - <p>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.</p> - - <p>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.</p> - </li> - - <li> - <p>Lend authority to other Developers.</p> - - <p>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.</p> - </li> - - <li> - <p>Make any decision which requires urgent action.</p> - - <p>This does not apply to decisions which have only become - gradually urgent through lack of relevant action, unless there is a - fixed deadline.</p> - </li> - - <li> - <p>Make any decision for whom noone else has responsibility.</p> - </li> - - <li> - <p>Propose draft General Resolutions and amendments.</p> - </li> - - <li> - <p>Together with the Technical Committee, appoint new members to - the Committee. (See §6.2.)</p> - </li> - - <li> - <p>Use a casting vote when Developers vote.</p> - - <p>The Project Leader also has a normal vote in such ballots.</p> - </li> - - <li> - <p>Vary the discussion period for Developers' votes (as above).</p> - </li> - - <li> - <p>Lead discussions amongst Developers.</p> - - <p>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.</p> - </li> - - <li> - <p>In consultation with the developers, make decisions affecting - property held in trust for purposes related to Debian. (See - §9.). Such decisions are communicated to the members by the - Project Leader or their Delegate(s). Major expenditures - should be proposed and debated on the mailing list before - funds are disbursed.</p> - </li> - <li> - <p>Add or remove organizations from the list of trusted - organizations (see §9.3) that are authorized to accept and - hold assets for Debian. The evaluation and discussion leading - up to such a decision occurs on an electronic mailing list - designated by the Project Leader or their Delegate(s), on - which any developer may post. There is a minimum discussion - period of two weeks before an organization may be added to - the list of trusted organizations.</p> - </li> -</ol> - -<h3>5.2. Appointment</h3> - -<ol> - <li>The Project Leader is elected by the Developers.</li> - - <li>The election begins six weeks before the leadership post becomes - vacant, or (if it is too late already) immediately.</li> - - <li>For the first week any Developer may nominate - themselves as a candidate Project Leader, and summarize their plans for their term.</li> - - <li>For three weeks after that no more candidates may be nominated; - candidates should use this time for campaigning and discussion. If - there are no candidates at the end of the nomination period then the - nomination period is extended for an additional week, repeatedly if - necessary.</li> - - <li>The next two 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.</li> - - <li>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.</li> - - <li> - 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 <q>None Of The Above</q>. - </li> - - <li>The Project Leader serves for one year from their election.</li> -</ol> - -<h3>5.3. Procedure</h3> - -<p>The Project Leader should attempt to make decisions which are -consistent with the consensus of the opinions of the Developers.</p> - -<p>Where practical the Project Leader should informally solicit the -views of the Developers.</p> - -<p>The Project Leader should avoid overemphasizing their own point of -view when making decisions in their capacity as Leader.</p> - -<toc-add-entry name="item-6">6. Technical committee</toc-add-entry> - -<h3>6.1. Powers</h3> - -<p>The <a href="tech-ctte">Technical Committee</a> may:</p> - -<ol> - <li> - <p>Decide on any matter of technical policy.</p> - - <p>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).)</p> - </li> - - <li> - <p>Decide any technical matter where Developers' jurisdictions - overlap.</p> - - <p>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.</p> - </li> - - <li> - <p>Make a decision when asked to do so.</p> - - <p>Any person or body may delegate a decision of their own to the - Technical Committee, or seek advice from it.</p> - </li> - - <li> - <p>Overrule a Developer (requires a 3:1 majority).</p> - - <p>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.</p> - </li> - - <li> - <p>Offer advice.</p> - - <p>The Technical Committee may make formal announcements about its - views on any matter. <cite>Individual members may of course make - informal statements about their views and about the likely views of - the committee.</cite></p> - </li> - - <li> - <p>Together with the Project Leader, appoint new members to itself - or remove existing members. (See §6.2.)</p> - </li> - - <li> - <p>Appoint the Chairman of the Technical Committee.</p> - - <p> - 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. - </p> - </li> - - <li> - <p>The Chairman can stand in for the Leader, together with the - Secretary</p> - - <p>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.</p> - </li> -</ol> - -<h3>6.2. Composition</h3> - -<ol> - <li> - <p>The Technical Committee consists of up to 8 Developers, and - should usually have at least 4 members.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>When there are 5 members or fewer the Technical Committee may - appoint new member(s) until the number of members reaches 6.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>A Developer is not eligible to be (re)appointed to the Technical - Committee if they have been a member within the previous 12 - months.</p> - </li> - - <li> - <p>If the Technical Committee and the Project Leader agree they - may remove or replace an existing member of the Technical - Committee.</p> - </li> - - <li> - <p>Term limit:</p> - <ol> - <li> - <p>On January 1st of each year the term of any Committee member - who has served more than 42 months (3.5 years) and who is one - of the two most senior members is set to expire on December - 31st of that year.</p> - </li> - <li> - <p>A member of the Technical Committee is said to be more - senior than another if they were appointed earlier, or were - appointed at the same time and have been a member of the - Debian Project longer. In the event that a member has been - appointed more than once, only the most recent appointment is - relevant.</p> - </li> - </ol> - </li> -</ol> - -<h3>6.3. Procedure</h3> - -<ol> - <li> - <p>The Technical Committee uses the Standard Resolution - Procedure.</p> - - <p>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.</p> - </li> - - <li> - <p>Details regarding voting</p> - - <p>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).</p> - </li> - - <li> - <p>Public discussion and decision-making.</p> - - <p>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.</p> - </li> - - <li> - <p>Confidentiality of appointments.</p> - - <p>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.</p> - </li> - - <li> - <p>No detailed design work.</p> - - <p>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.</p> - - <p>The Technical Committee restricts itself to choosing from or - adopting compromises between solutions and decisions which have - been proposed and reasonably thoroughly discussed elsewhere.</p> - - <p><cite>Individual members of the technical committee may of - course participate on their own behalf in any aspect of design and - policy work.</cite></p> - </li> - - <li> - <p>Technical Committee makes decisions only as last resort.</p> - - <p>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.</p> - </li> -</ol> - -<toc-add-entry name="item-7">7. The Project Secretary</toc-add-entry> - -<h3>7.1. Powers</h3> - -<p>The <a href="secretary">Secretary</a>:</p> - -<ol> - <li> - <p>Takes votes amongst the Developers, and determines the number - and identity of Developers, whenever this is required by the - constitution.</p> - </li> - - <li> - <p>Can stand in for the Leader, together with the Chairman of the - Technical Committee.</p> - - <p>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.</p> - </li> - - <li> - <p>Adjudicates any disputes about interpretation of the - constitution.</p> - </li> - - <li> - <p>May delegate part or all of their authority to someone else, or - withdraw such a delegation at any time.</p> - </li> -</ol> - -<h3>7.2. Appointment</h3> - -<p>The Project Secretary is appointed by the Project Leader and the -current Project Secretary.</p> - -<p>If the Project Leader and the current Project Secretary cannot agree -on a new appointment, they must ask the Developers by way of -General Resolution to appoint a Secretary.</p> - -<p>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.</p> - -<p>The Project Secretary's term of office is 1 year, at which point -they or another Secretary must be (re)appointed.</p> - -<h3>7.3. Procedure</h3> - -<p>The Project Secretary should make decisions which are fair and -reasonable, and preferably consistent with the consensus of the -Developers.</p> - -<p>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.</p> - -<toc-add-entry name="item-8">8. The Project Leader's Delegates</toc-add-entry> - -<h3>8.1. Powers</h3> - -<p>The Project Leader's Delegates:</p> - -<ol> - <li>have powers delegated to them by the Project Leader;</li> - - <li>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. <cite>This is to - avoid concentration of power, particularly over membership as a - Developer, in the hands of the Project Leader.</cite></li> -</ol> - -<h3>8.2. Appointment</h3> - -<p>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.</p> - -<h3>8.3. Procedure</h3> - -<p>Delegates may make decisions as they see fit, but should attempt to -implement good technical decisions and/or follow consensus opinion.</p> - -<toc-add-entry name="item-9">9. Assets held in trust for Debian</toc-add-entry> - -<p>In most jurisdictions around the world, the Debian project is not -in a position to directly hold funds or other property. Therefore, -property has to be owned by any of a number of organisations as -detailed in §9.2.</p> - -<p>Traditionally, SPI was the sole organisation authorized to hold -property and monies for the Debian Project. SPI was created in -the U.S. to hold money in trust there.</p> - -<p><a href="https://www.spi-inc.org/">SPI</a> and Debian are separate -organisations who share some goals. -Debian is grateful for the legal support framework offered by SPI.</p> - -<h3>9.1. Relationship with Associated Organizations</h3> - -<ol> - <li> - <p>Debian Developers do not become agents or employees of - organisations holding assets in trust for Debian, or of - each other, or of persons in authority in the Debian Project, - solely by the virtue of being Debian Developers. A person - acting as a Developer does so as an individual, on their own - behalf. Such organisations may, of their own accord, - establish relationships with individuals who are also Debian - developers.</p> - </li> -</ol> - -<h3>9.2. Authority</h3> - -<ol> - <li> - <p>An organisation holding assets for Debian has no authority - regarding Debian's technical or nontechnical decisions, except - that no decision by Debian with respect to any property held - by the organisation shall require it to act outside its legal - authority.</p> - </li> - <li> - <p>Debian claims no authority over an organisation that holds - assets for Debian other than that over the use of property - held in trust for Debian.</p> - </li> -</ol> - -<h3>9.3. Trusted organisations</h3> - -<p>Any donations for the Debian Project must be made to any one of a -set of organisations designated by the Project leader (or a -delegate) to be authorized to handle assets to be used for the -Debian Project.</p> - -<p>Organisations holding assets in trust for Debian should -undertake reasonable obligations for the handling of such -assets.</p> - -<p>Debian maintains a public List of Trusted Organisations that -accept donations and hold assets in trust for Debian -(including both tangible property and intellectual property) -that includes the commitments those organisations have made as -to how those assets will be handled.</p> - -<toc-add-entry name="item-A">A. Standard Resolution Procedure</toc-add-entry> - -<p>These rules apply to communal decision-making by committees and -plebiscites, where stated above.</p> - -<h3>A.0. Proposal</h3> - -<p>The formal procedure begins when a draft resolution is proposed and -sponsored, as required.</p> - -<h3>A.1. Discussion and Amendment</h3> - -<ol> - <li>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.</li> - - <li>A formal amendment may be accepted by the resolution's proposer, - in which case the formal resolution draft is immediately changed to - match.</li> - - <li>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.</li> - - <li>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).)</li> - - <li>The proposer of a resolution may suggest changes to the wordings - of amendments; these take effect if the proposer of the amendment - agrees and none of the sponsors object. In this case the changed - amendments will be voted on instead of the originals.</li> - - <li>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.</li> -</ol> - -<h3>A.2. Calling for a vote</h3> - -<ol> - <li>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.</li> - - <li> - The proposer or any sponsor of a resolution may call for a vote on that - resolution and all related amendments. - </li> - - <li>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).</li> - - <li> - 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. - </li> -</ol> - -<h3>A.3. Voting procedure</h3> - -<ol> - <li> - 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). - </li> - - <li> - The default option must not have any supermajority requirements. - Options which do not have an explicit supermajority requirement - have a 1:1 majority requirement. - </li> - - <li> - The votes are counted according to the rules in A.6. The - default option is <q>Further Discussion</q>, unless specified - otherwise. - </li> - - <li>In cases of doubt the Project Secretary shall decide on matters - of procedure.</li> -</ol> - -<h3>A.4. Withdrawing resolutions or unaccepted amendments</h3> - -<p>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.</p> - -<p>A sponsor of a resolution or amendment (unless it has been -accepted) may withdraw.</p> - -<p>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.</p> - -<h3>A.5. Expiry</h3> - -<p> - 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. -</p> - -<p> - The secretary may also include suggestions on how to proceed, - if appropriate. -</p> - -<h3>A.6. Vote Counting</h3> - -<ol> - <li> 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. - </li> - <li> 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. - </li> - <li> Any (non-default) option which does not defeat the default option - by its required majority ratio is dropped from consideration. - <ol> - <li> - Given two options A and B, V(A,B) is the number of voters - who prefer option A over option B. - </li> - <li> - An option A defeats the default option D by a majority - ratio N, if V(A,D) is greater or equal to N * V(D,A) and V(A,D) is strictly greater than V(D,A). - </li> - <li> - If a supermajority of S:1 is required for A, its majority ratio - is S; otherwise, its majority ratio is 1. - </li> - </ol> - </li> - <li> From the list of undropped options, we generate a list of - pairwise defeats. - <ol> - <li> - An option A defeats an option B, if V(A,B) is strictly greater - than V(B,A). - </li> - </ol> - </li> - <li> From the list of [undropped] pairwise defeats, we generate a - set of transitive defeats. - <ol> - <li> - 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. - </li> - </ol> - </li> - <li> We construct the Schwartz set from the set of transitive defeats. - <ol> - <li> - 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. - </li> - </ol> - </li> - <li> 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. - <ol> - <li> - 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). - </li> - <li> - A weakest defeat is a defeat that has no other defeat weaker - than it. There may be more than one such defeat. - </li> - </ol> - </li> - <li> 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. - </li> -</ol> - -<p> - <strong>Note:</strong> 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. -</p> - -<p><cite>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.</cite></p> - -<toc-add-entry name="item-B">B. Use of language and typography</toc-add-entry> - -<p>The present indicative (<q>is</q>, for example) means that the statement -is a rule in this constitution. <q>May</q> or <q>can</q> indicates that the -person or body has discretion. <q>Should</q> means that it would be -considered a good thing if the sentence were obeyed, but it is not -binding. <cite>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.</cite></p> diff --git a/greek/devel/constitution.wml b/greek/devel/constitution.wml deleted file mode 100644 index 3b2c15b6b6f..00000000000 --- a/greek/devel/constitution.wml +++ /dev/null @@ -1,997 +0,0 @@ -#use wml::debian::template title="Καταστατικό του Debian" BARETITLE="true" -#use wml::debian::toc -#use wml::debian::translation-check translation="e3d525d9f092f9014e00417cc847900ac5a99649" maintainer="galaxico" mindelta="-1" maxdelta="1" - -<h1>Καταστατικό για το Σχέδιο Debian (v1.7)</h1> - -<p>η έκδοση 1.7 επικυρώθηκε στις 15 Αυγούστου 2016. Αντικαθιστά τις: -<a href="constitution.1.6">έκδοση 1.6</a> που επικυρώθηκε στις 13 Δεκεμβρίου 2015, -<a href="constitution.1.5">έκδοση 1.5</a> που επικυρώθηκε στις 9 Ιανουαρίου 2015, -<a href="constitution.1.4">έκδοση 1.4</a> που επικυρώθηκε στις 7 Οκτωβρίου 2007, -<a href="constitution.1.3">έκδοση 1.3</a> που επικυρώθηκε στις 24 Σεπτεμβρίου 2006, -<a href="constitution.1.2">έκδοση 1.2</a> που επικυρώθηκε στις 29 Οκτωβρίου 2003 και -<a href="constitution.1.1">έκδοση 1.1</a> που επικυρώθηκε στις 21 Ιουνίου 2003, -που αντικαθιστά η ίδια την <a href="constitution.1.0">έκδοση 1.0</a> -που επικυρώθηκε στις 2 Δεκεμβρίου 1998.</p> - -<toc-display /> - -<toc-add-entry name="item-1">1. Εισαγωγή</toc-add-entry> - -<p><cite>Το Σχέδιο Debian είναι μια ένωση ατόμων που έχουν θέσει σαν κοινό -στόχο την δημιουργία ενός ελεύθερου λειτουργικού συστήματος.</cite></p> - -<p>Το παρόν κείμενο περιγράφει την οργανωτική δομή για την τυπική διαδικασία λήψης αποφάσεων του Σχεδίου. -Δεν περιγράφει τους στόχους του Σχεδίου ή πώς τους επιτυγχάνει ούτε περιέχει οποιεσδήποτε -πολιτικές εκτός από αυτές που σχετίζονται άμεσα με τη διαδικασία λήψης αποφάσεων.</p> - -<toc-add-entry name="item-2">2. Σώματα και άτομα λήψης αποφάσεων</toc-add-entry> - -<p>Οποιαδήποτε απόφαση του Σχεδίου λαμβάνεται από ένα ή περισσότερα -από τα ακόλουθα:</p> - -<ol> - <li>Τους/Τις προγραμματιστές/προγραμματίστριες, μέσω μιας Γενικής Συνέλευσης ή μιας εκλογής·</li> - - <li>Τον/Την Επικεφαλής του Σχεδίου·</li> - - <li>Την Τεχνική Επιτροπή και/ή τον/την Πρόεδρό της·</li> - - <li>Τον μεμονωμένο προγραμματιστή/την μεμονωμένη προγραμματίστρια που - δουλεύει πάνω σε ένα συγκεκριμένο καθήκον·</li> - - <li>Εκπροσώπους που έχουν οριστεί από τον/την Επικεφαλής του Σχεδίου για - συγκεκριμένα καθήκοντα·</li> - - <li>The Project Secretary.</li> -</ol> - -<p>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. <cite>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.</cite></p> - -<h3>2.1. General rules</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>A person may hold several posts, except that the Project Leader, - Project Secretary and the Chair of the Technical Committee must - be distinct, and that the Leader cannot appoint themselves as their - own Delegate.</p> - </li> - - <li> - <p>A person may leave the Project or resign from a particular post - they hold, at any time, by stating so publicly.</p> - </li> -</ol> - -<toc-add-entry name="item-3">3. Individual Developers</toc-add-entry> - -<h3>3.1. Powers</h3> - -<p>An individual Developer may</p> - -<ol> - <li>make any technical or nontechnical decision with regard to their - own work;</li> - - <li>propose or sponsor draft General Resolutions;</li> - - <li>propose themselves as a Project Leader candidate in - elections;</li> - - <li>vote on General Resolutions and in Leadership elections.</li> -</ol> - -<h3>3.2. Composition and appointment</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>The Project Leader's Delegate(s) may choose not to admit new - Developers, or expel existing Developers. <cite>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.</cite></p> - </li> -</ol> - -<h3>3.3. Procedure</h3> - -<p>Developers may make these decisions as they see fit.</p> - -<toc-add-entry name="item-4">4. The Developers by way of General Resolution or election</toc-add-entry> - -<h3>4.1. Powers</h3> - -<p>Together, the Developers may:</p> - -<ol> - <li> - <p>Appoint or recall the Project Leader.</p> - </li> - - <li> - <p>Amend this constitution, provided they agree with a 3:1 - majority.</p> - </li> - - <li> - <p>Make or override any decision authorised by the powers of the Project - Leader or a Delegate.</p> - </li> - - <li> - <p>Make or override any decision authorised by the powers of the Technical - Committee, provided they agree with a 2:1 majority.</p> - </li> - - <li> - <p>Issue, supersede and withdraw nontechnical policy documents and - statements.</p> - - <p>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.</p> - - <p>They may also include position statements about issues of the - day.</p> - - <ol style="list-style: decimal;"> - <li>A Foundation Document is a document or statement regarded as - critical to the Project's mission and purposes.</li> - <li>The Foundation Documents are the works entitled <q>Debian - Social Contract</q> and <q>Debian Free Software Guidelines</q>.</li> - <li>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.</li> - </ol> - - </li> - - <li> - <p>Make decisions about property held in trust for purposes - related to Debian. (See §9.).</p> - </li> - - <li> - <p>In case of a disagreement between the project leader and - the incumbent secretary, appoint a new secretary.</p> - </li> -</ol> - -<h3>4.2. Procedure</h3> - -<ol> - <li> - <p>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.</p> - </li> - - <li> - <p>Delaying a decision by the Project Leader or their Delegate:</p> - - <ol> - <li>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 §4.1(3).</li> - - <li>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).</li> - - <li>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.</li> - - <li>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.</li> - - <li>If the Project Leader (or the Delegate) withdraws the - original decision, the vote becomes moot, and is no longer - conducted.</li> - </ol> - </li> - - <li> - <p> - 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. - </p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>Votes are cast by email in a manner suitable to the Secretary. - The Secretary determines for each poll whether voters can change - their votes.</p> - </li> - - <li> - <p>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.</p> - </li> -</ol> - -<toc-add-entry name="item-5">5. Project Leader</toc-add-entry> - -<h3>5.1. Powers</h3> - -<p>The <a href="leader">Project Leader</a> may:</p> - -<ol> - <li> - <p>Appoint Delegates or delegate decisions to the Technical - Committee.</p> - - <p>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.</p> - - <p>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.</p> - </li> - - <li> - <p>Lend authority to other Developers.</p> - - <p>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.</p> - </li> - - <li> - <p>Make any decision which requires urgent action.</p> - - <p>This does not apply to decisions which have only become - gradually urgent through lack of relevant action, unless there is a - fixed deadline.</p> - </li> - - <li> - <p>Make any decision for whom noone else has responsibility.</p> - </li> - - <li> - <p>Propose draft General Resolutions and amendments.</p> - </li> - - <li> - <p>Together with the Technical Committee, appoint new members to - the Committee. (See §6.2.)</p> - </li> - - <li> - <p>Use a casting vote when Developers vote.</p> - - <p>The Project Leader also has a normal vote in such ballots.</p> - </li> - - <li> - <p>Vary the discussion period for Developers' votes (as above).</p> - </li> - - <li> - <p>Lead discussions amongst Developers.</p> - - <p>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.</p> - </li> - - <li> - <p>In consultation with the developers, make decisions affecting - property held in trust for purposes related to Debian. (See - §9.). Such decisions are communicated to the members by the - Project Leader or their Delegate(s). Major expenditures - should be proposed and debated on the mailing list before - funds are disbursed.</p> - </li> - <li> - <p>Add or remove organizations from the list of trusted - organizations (see §9.3) that are authorized to accept and - hold assets for Debian. The evaluation and discussion leading - up to such a decision occurs on an electronic mailing list - designated by the Project Leader or their Delegate(s), on - which any developer may post. There is a minimum discussion - period of two weeks before an organization may be added to - the list of trusted organizations.</p> - </li> -</ol> - -<h3>5.2. Appointment</h3> - -<ol> - <li>The Project Leader is elected by the Developers.</li> - - <li>The election begins six weeks before the leadership post becomes - vacant, or (if it is too late already) immediately.</li> - - <li>For the first week any Developer may nominate - themselves as a candidate Project Leader, and summarize their plans for their term.</li> - - <li>For three weeks after that no more candidates may be nominated; - candidates should use this time for campaigning and discussion. If - there are no candidates at the end of the nomination period then the - nomination period is extended for an additional week, repeatedly if - necessary.</li> - - <li>The next two 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.</li> - - <li>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.</li> - - <li> - 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 <q>None Of The Above</q>. - </li> - - <li>The Project Leader serves for one year from their election.</li> -</ol> - -<h3>5.3. Procedure</h3> - -<p>The Project Leader should attempt to make decisions which are -consistent with the consensus of the opinions of the Developers.</p> - -<p>Where practical the Project Leader should informally solicit the -views of the Developers.</p> - -<p>The Project Leader should avoid overemphasizing their own point of -view when making decisions in their capacity as Leader.</p> - -<toc-add-entry name="item-6">6. Technical committee</toc-add-entry> - -<h3>6.1. Powers</h3> - -<p>The <a href="tech-ctte">Technical Committee</a> may:</p> - -<ol> - <li> - <p>Decide on any matter of technical policy.</p> - - <p>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).)</p> - </li> - - <li> - <p>Decide any technical matter where Developers' jurisdictions - overlap.</p> - - <p>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.</p> - </li> - - <li> - <p>Make a decision when asked to do so.</p> - - <p>Any person or body may delegate a decision of their own to the - Technical Committee, or seek advice from it.</p> - </li> - - <li> - <p>Overrule a Developer (requires a 3:1 majority).</p> - - <p>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.</p> - </li> - - <li> - <p>Offer advice.</p> - - <p>The Technical Committee may make formal announcements about its - views on any matter. <cite>Individual members may of course make - informal statements about their views and about the likely views of - the committee.</cite></p> - </li> - - <li> - <p>Together with the Project Leader, appoint new members to itself - or remove existing members. (See §6.2.)</p> - </li> - - <li> - <p>Appoint the Chair of the Technical Committee.</p> - - <p> - The Chair 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. - </p> - </li> - - <li> - <p>The Chair can stand in for the Leader, together with the - Secretary</p> - - <p>As detailed in §7.1(2), the Chair of the Technical - Committee and the Project Secretary may together stand in for the - Leader if there is no Leader.</p> - </li> -</ol> - -<h3>6.2. Composition</h3> - -<ol> - <li> - <p>The Technical Committee consists of up to 8 Developers, and - should usually have at least 4 members.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>When there are 5 members or fewer the Technical Committee may - appoint new member(s) until the number of members reaches 6.</p> - </li> - - <li> - <p>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.</p> - </li> - - <li> - <p>A Developer is not eligible to be (re)appointed to the Technical - Committee if they have been a member within the previous 12 - months.</p> - </li> - - <li> - <p>If the Technical Committee and the Project Leader agree they - may remove or replace an existing member of the Technical - Committee.</p> - </li> - - <li> - <p>Term limit:</p> - <ol> - <li> - <p>On January 1st of each year the term of any Committee member - who has served more than 42 months (3.5 years) and who is one - of the two most senior members is set to expire on December - 31st of that year.</p> - </li> - <li> - <p>A member of the Technical Committee is said to be more - senior than another if they were appointed earlier, or were - appointed at the same time and have been a member of the - Debian Project longer. In the event that a member has been - appointed more than once, only the most recent appointment is - relevant.</p> - </li> - </ol> - </li> -</ol> - -<h3>6.3. Procedure</h3> - -<ol> - <li> - <p>The Technical Committee uses the Standard Resolution - Procedure.</p> - - <p>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.</p> - </li> - - <li> - <p>Details regarding voting</p> - - <p>The Chair 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 Chair, in which case they may use only their casting - vote).</p> - </li> - - <li> - <p>Public discussion and decision-making.</p> - - <p>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.</p> - </li> - - <li> - <p>Confidentiality of appointments.</p> - - <p>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.</p> - </li> - - <li> - <p>No detailed design work.</p> - - <p>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.</p> - - <p>The Technical Committee restricts itself to choosing from or - adopting compromises between solutions and decisions which have - been proposed and reasonably thoroughly discussed elsewhere.</p> - - <p><cite>Individual members of the technical committee may of - course participate on their own behalf in any aspect of design and - policy work.</cite></p> - </li> - - <li> - <p>Technical Committee makes decisions only as last resort.</p> - - <p>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.</p> - </li> -</ol> - -<toc-add-entry name="item-7">7. The Project Secretary</toc-add-entry> - -<h3>7.1. Powers</h3> - -<p>The <a href="secretary">Secretary</a>:</p> - -<ol> - <li> - <p>Takes votes amongst the Developers, and determines the number - and identity of Developers, whenever this is required by the - constitution.</p> - </li> - - <li> - <p>Can stand in for the Leader, together with the Chair of the - Technical Committee.</p> - - <p>If there is no Project Leader then the Chair of the - Technical Committee and the Project Secretary may by joint - agreement make decisions if they consider it imperative to do - so.</p> - </li> - - <li> - <p>Adjudicates any disputes about interpretation of the - constitution.</p> - </li> - - <li> - <p>May delegate part or all of their authority to someone else, or - withdraw such a delegation at any time.</p> - </li> -</ol> - -<h3>7.2. Appointment</h3> - -<p>The Project Secretary is appointed by the Project Leader and the -current Project Secretary.</p> - -<p>If the Project Leader and the current Project Secretary cannot agree -on a new appointment, they must ask the Developers by way of -General Resolution to appoint a Secretary.</p> - -<p>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 Chair of the Technical -Committee, as Acting Secretary.</p> - -<p>The Project Secretary's term of office is 1 year, at which point -they or another Secretary must be (re)appointed.</p> - -<h3>7.3. Procedure</h3> - -<p>The Project Secretary should make decisions which are fair and -reasonable, and preferably consistent with the consensus of the -Developers.</p> - -<p>When acting together to stand in for an absent Project Leader the -Chair 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.</p> - -<toc-add-entry name="item-8">8. The Project Leader's Delegates</toc-add-entry> - -<h3>8.1. Powers</h3> - -<p>The Project Leader's Delegates:</p> - -<ol> - <li>have powers delegated to them by the Project Leader;</li> - - <li>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. <cite>This is to - avoid concentration of power, particularly over membership as a - Developer, in the hands of the Project Leader.</cite></li> -</ol> - -<h3>8.2. Appointment</h3> - -<p>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.</p> - -<h3>8.3. Procedure</h3> - -<p>Delegates may make decisions as they see fit, but should attempt to -implement good technical decisions and/or follow consensus opinion.</p> - -<toc-add-entry name="item-9">9. Assets held in trust for Debian</toc-add-entry> - -<p>In most jurisdictions around the world, the Debian project is not -in a position to directly hold funds or other property. Therefore, -property has to be owned by any of a number of organisations as -detailed in §9.2.</p> - -<p>Traditionally, SPI was the sole organisation authorized to hold -property and monies for the Debian Project. SPI was created in -the U.S. to hold money in trust there.</p> - -<p><a href="https://www.spi-inc.org/">SPI</a> and Debian are separate -organisations who share some goals. -Debian is grateful for the legal support framework offered by SPI.</p> - -<h3>9.1. Relationship with Associated Organizations</h3> - -<ol> - <li> - <p>Debian Developers do not become agents or employees of - organisations holding assets in trust for Debian, or of - each other, or of persons in authority in the Debian Project, - solely by the virtue of being Debian Developers. A person - acting as a Developer does so as an individual, on their own - behalf. Such organisations may, of their own accord, - establish relationships with individuals who are also Debian - developers.</p> - </li> -</ol> - -<h3>9.2. Authority</h3> - -<ol> - <li> - <p>An organisation holding assets for Debian has no authority - regarding Debian's technical or nontechnical decisions, except - that no decision by Debian with respect to any property held - by the organisation shall require it to act outside its legal - authority.</p> - </li> - <li> - <p>Debian claims no authority over an organisation that holds - assets for Debian other than that over the use of property - held in trust for Debian.</p> - </li> -</ol> - -<h3>9.3. Trusted organisations</h3> - -<p>Any donations for the Debian Project must be made to any one of a -set of organisations designated by the Project leader (or a -delegate) to be authorized to handle assets to be used for the -Debian Project.</p> - -<p>Organisations holding assets in trust for Debian should -undertake reasonable obligations for the handling of such -assets.</p> - -<p>Debian maintains a public List of Trusted Organisations that -accept donations and hold assets in trust for Debian -(including both tangible property and intellectual property) -that includes the commitments those organisations have made as -to how those assets will be handled.</p> - -<toc-add-entry name="item-A">A. Standard Resolution Procedure</toc-add-entry> - -<p>These rules apply to communal decision-making by committees and -plebiscites, where stated above.</p> - -<h3>A.0. Proposal</h3> - -<p>The formal procedure begins when a draft resolution is proposed and -sponsored, as required.</p> - -<h3>A.1. Discussion and Amendment</h3> - -<ol> - <li>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.</li> - - <li>A formal amendment may be accepted by the resolution's proposer, - in which case the formal resolution draft is immediately changed to - match.</li> - - <li>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.</li> - - <li>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).)</li> - - <li>The proposer of a resolution may suggest changes to the wordings - of amendments; these take effect if the proposer of the amendment - agrees and none of the sponsors object. In this case the changed - amendments will be voted on instead of the originals.</li> - - <li>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.</li> -</ol> - -<h3>A.2. Calling for a vote</h3> - -<ol> - <li>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.</li> - - <li> - The proposer or any sponsor of a resolution may call for a vote on that - resolution and all related amendments. - </li> - - <li>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).</li> - - <li> - 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. - </li> -</ol> - -<h3>A.3. Voting procedure</h3> - -<ol> - <li> - 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). - </li> - - <li> - The default option must not have any supermajority requirements. - Options which do not have an explicit supermajority requirement - have a 1:1 majority requirement. - </li> - - <li> - The votes are counted according to the rules in A.6. The - default option is <q>Further Discussion</q>, unless specified - otherwise. - </li> - - <li>In cases of doubt the Project Secretary shall decide on matters - of procedure.</li> -</ol> - -<h3>A.4. Withdrawing resolutions or unaccepted amendments</h3> - -<p>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.</p> - -<p>A sponsor of a resolution or amendment (unless it has been -accepted) may withdraw.</p> - -<p>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.</p> - -<h3>A.5. Expiry</h3> - -<p> - 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. -</p> - -<p> - The secretary may also include suggestions on how to proceed, - if appropriate. -</p> - -<h3>A.6. Vote Counting</h3> - -<ol> - <li> 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. - </li> - <li> 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. - </li> - <li> Any (non-default) option which does not defeat the default option - by its required majority ratio is dropped from consideration. - <ol> - <li> - Given two options A and B, V(A,B) is the number of voters - who prefer option A over option B. - </li> - <li> - An option A defeats the default option D by a majority - ratio N, if V(A,D) is greater or equal to N * V(D,A) and V(A,D) is strictly greater than V(D,A). - </li> - <li> - If a supermajority of S:1 is required for A, its majority ratio - is S; otherwise, its majority ratio is 1. - </li> - </ol> - </li> - <li> From the list of undropped options, we generate a list of - pairwise defeats. - <ol> - <li> - An option A defeats an option B, if V(A,B) is strictly greater - than V(B,A). - </li> - </ol> - </li> - <li> From the list of [undropped] pairwise defeats, we generate a - set of transitive defeats. - <ol> - <li> - 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. - </li> - </ol> - </li> - <li> We construct the Schwartz set from the set of transitive defeats. - <ol> - <li> - 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. - </li> - </ol> - </li> - <li> 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. - <ol> - <li> - 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). - </li> - <li> - A weakest defeat is a defeat that has no other defeat weaker - than it. There may be more than one such defeat. - </li> - </ol> - </li> - <li> 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. - </li> -</ol> - -<p> - <strong>Note:</strong> 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. -</p> - -<p><cite>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.</cite></p> - -<toc-add-entry name="item-B">B. Use of language and typography</toc-add-entry> - -<p>The present indicative (<q>is</q>, for example) means that the statement -is a rule in this constitution. <q>May</q> or <q>can</q> indicates that the -person or body has discretion. <q>Should</q> means that it would be -considered a good thing if the sentence were obeyed, but it is not -binding. <cite>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.</cite></p> diff --git a/greek/devel/debian-accessibility/Makefile b/greek/devel/debian-accessibility/Makefile deleted file mode 100644 index c26323c0c92..00000000000 --- a/greek/devel/debian-accessibility/Makefile +++ /dev/null @@ -1 +0,0 @@ -include $(subst webwml/greek,webwml/english,$(CURDIR))/Makefile diff --git a/greek/devel/debian-accessibility/index.wml b/greek/devel/debian-accessibility/index.wml deleted file mode 100644 index b06755c1e72..00000000000 --- a/greek/devel/debian-accessibility/index.wml +++ /dev/null @@ -1,114 +0,0 @@ -#use wml::debian::template title="Debian-Accessibility" -#use wml::debian::translation-check translation="82f3d1721149ec88f5974028ed2c2d8d454b4071" maintainer="galaxico" -{#style#:<link rel="stylesheet" href="style.css" type="text/css" />:#style#} - -<h2>Project description</h2> - -<p>Debian-Accessibility is an internal project to develop Debian into an - operating system that is particularly well fit for the requirements of - people with disabilities. - The goal of Debian-Accessibility is a completely accessible system - which offers users with disabilities the highest possible amount - of independence, built completely on free software. -</p> -<p>We envisage that Debian-Accessibility will add value to existing - packages by providing patches to fix problems very specific - to certain user groups or conducting Accessibility validation tests and - providing modification suggestions based on the results. -</p> - -<h2><a id="email-list" name="email-list">Email List</a></h2> - -<p>The Debian-Accessibility mailing list is the central point of communication - for Debian-Accessibility. It serves as a forum for potential, as - well as current, users of the Debian system who do have special needs. - Additionally, it is used to coordinate development efforts around the various - topics of Accessibility. You can subscribe to and unsubscribe from it using - <a href="https://lists.debian.org/debian-accessibility/">the list web - page</a>, and also read the - <a href="https://lists.debian.org/debian-accessibility/">list archives</a>. -</p> - -<h2><a id="projects" name="projects">Relevant Software</a></h2> - -<p>The first attempt to put the software into categories might be not the - best. Send any suggestions for improvements to <a href="#email-list">the - mailing list</a>, or to <a href="mailto:sthibault@debian.org">Samuel Thibault</a>. -</p> -<ul> - <li><a href="software#speech-synthesis">Speech synthesis and related - APIs</a></li> - <li><a href="software#console">Console (text-mode) screen - readers</a></li> - <li><a href="software#emacs">Screen review extensions for - Emacs</a></li> - <li><a href="software#gui">Graphical User Interfaces</a>: - <ul> - <li><a href="software#gnome">GNOME Accessibility</a></li> - <li><a href="software#input">Non-standard input - methods</a></li> - </ul></li> -</ul> - -<h2><a id="goals" name="goals">Project goals</a></h2> - -<ul> - <li>Provide information and documentation of Accessibility.</li> - <li>Ensure that Accessibility software like drivers for specialized - peripheral devices can be loaded if necessary as early as possible in the - system startup phase, including the Debian installation process. This is - to ensure that people with special needs retain a high level of - independence during maintenance of their own systems.</li> - <li>Verify and ensure that Debian core infrastructure like our Web site does - comply with Accessibility Guidelines.</li> - <li>Bring authors of different projects with similar goals together.</li> - <li>Help upstream authors to get their products packaged for Debian.</li> - <li>Show commercial assistive technology vendors the strengths of Free - Software based systems and make them consider to port their software to - Linux or even to switch to Open Source.</li> -</ul> - -<h2><a id="help" name="help">What can I do to help?</a></h2> - -<ul> - <li>Work on enhancing and translating these web pages.</li> - <li>Create a logo.</li> - <li>Documentation and translation.</li> - <li>Internationalization (which is more than just translating, see - <a href="software#i18nspeech">internationalized speech - synthesis</a> for some ideas).</li> - <li>Verify that the debian.org web site is Accessible according to - established Accessibility Guidelines and submit enhancement suggestions - based on your findings. It could eventually be desirable to apply for - something like Bobby Approval at some point.</li> -</ul> - -<h2><a id="links" name="links">Links</a></h2> - -<ul> - <li>The <a href="https://wiki.debian.org/accessibility">Debian Accessibility Wiki</a>.</li> - <li>The <a href="https://wiki.debian.org/accessibility-maint">Debian Accessibility Wiki for all Debian maintainers</a>.</li> - <li>The <a href="https://wiki.debian.org/accessibility-devel">Debian Accessibility Developer Wiki</a>.</li> - <li>The <a href="https://wiki.linuxfoundation.org/accessibility/start">Free Standards Group Accessibility - Workgroup</a>.</li> - <li>The <a href="https://wiki.gnome.org/Accessibility">GNOME - Accessibility Project</a>.</li> - <li>The <a href="https://community.kde.org/Accessibility">KDE Accessibility - Project</a>.</li> - <li><a href="https://wiki.ubuntu.com/Accessibility">Ubuntu Accessibility</a></li> - <li><a href="http://leb.net/blinux/">BLINUX</a>: Improve usability of the - GNU/Linux operating system for the user who is blind.</li> - <li><a href="http://www.linux-speakup.org/">The Linux Speakup - Project</a>.</li> - <li><a href="http://www.w3.org/WAI/">W3C's Web Accessibility Initiative - (WAI)</a>: - <ul> - <li>The <a href="http://www.w3.org/TR/WCAG10/">Web Content - Accessibility Guidelines</a> explain in detail how to make a Web - site accessible for people with a variety of disabilities.</li> - <li>The <a href="http://www.w3.org/TR/ATAG10/">Authoring Tool - Accessibility Guidelines</a> explain how to make a variety of - authoring tools support the production of accessible Web - content, and also how to make the software itself accessible.</li> - </ul></li> -</ul> diff --git a/greek/devel/debian-accessibility/software.wml b/greek/devel/debian-accessibility/software.wml deleted file mode 100644 index 61dbb6e1863..00000000000 --- a/greek/devel/debian-accessibility/software.wml +++ /dev/null @@ -1,401 +0,0 @@ -#use wml::debian::template title="Debian-Accessibility - Software" -#use wml::debian::translation-check translation="82f3d1721149ec88f5974028ed2c2d8d454b4071" maintainer="galaxico" -{#style#:<link rel="stylesheet" href="style.css" type="text/css" />:#style#} - -<define-tag a11y-pkg endtag=required> -<preserve name tag url/> -<set-var %attributes> -<h3><if "<get-var url>" - <a href="<get-var url>" name="<get-var tag>"><get-var name></a> - <a href="https://packages.debian.org/<get-var tag>" name="<get-var tag>"><get-var name></a>></h3> - %body -<restore name tag url/> -</define-tag> - -<h2><a id="speech-synthesis" name="speech-synthesis">Speech Synthesis and related APIs</a></h2> - -<p> - A thorough list is available on the - <a href="https://blends.debian.org/accessibility/tasks/speechsynthesis">speechsynthesis task page</a> -</p> - -<a11y-pkg name="EFlite" tag=eflite url="http://eflite.sourceforge.net/"> -<p> - A speech server for <a href="#emacspeak">Emacspeak</a> and - <a href="#yasr">yasr</a> (or other screen readers) that allows them to - interface with <a href="#flite">Festival Lite</a>, a free text-to-speech - engine developed at the CMU Speech Center as an off-shoot of - <a href="#festival">Festival</a>. -</p> -<p> - Due to limitations inherited from its backend, EFlite does only provide - support for the English language at the moment. -</p> -</a11y-pkg> -<a11y-pkg name="eSpeak" tag=espeak> -<p> -eSpeak/eSpeak-NG is a software speech synthesizer for English, and some other -languages. -</p> -<p> -eSpeak produces good quality English speech. It uses a different synthesis -method from other open source text to speech (TTS) engines (no concatenative -speech synthesis, therefore it also has a very small footprint), and sounds -quite different. It's perhaps not as natural or <q>smooth</q>, but some find the -articulation clearer and easier to listen to for long periods. -</p> -<p> -It can run as a command line program to speak text from a file or from stdin. -It also works well as a <q>Talker</q> with the KDE text to speech system (KTTS), -as an alternative to <a href="#festival">Festival</a> for example. As such, it -can speak text which has been selected into the clipboard, or directly from the -Konqueror browser or the Kate editor. -</p> - <ul> - <li>Includes different Voices, whose characteristics can be altered.</li> - <li>Can produce speech output as a WAV file.</li> - <li>Can translate text to phoneme codes, so it could be adapted as a front end - for another speech synthesis engine.</li> - <li>Potential for other languages. Rudimentary (and probably humourous) - attempts at German and Esperanto are included.</li> - <li>Compact size. The program and its data total about 350 kbytes.</li> - <li>Written in C++.</li> - </ul> -<p> -eSpeak can also be used with <a href="#speech-dispatcher">Speech Dispatcher</a>. -</p> -</a11y-pkg> -<a11y-pkg name="Festival Lite" tag=flite> -<p> - A small fast run-time speech synthesis engine. It is the latest - addition to the suite of free software synthesis tools including - University of Edinburgh's Festival Speech Synthesis System and - Carnegie Mellon University's FestVox project, tools, scripts and - documentation for building synthetic voices. However, flite itself - does not require either of these systems to run. -</p> -<p> - It currently only supports the English language. -</p> -</a11y-pkg> -<a11y-pkg name="Festival" tag="festival" - url="http://www.cstr.ed.ac.uk/projects/festival/"> -<p> - A general multi-lingual speech synthesis system developed - at the <a href="http://www.cstr.ed.ac.uk/">CSTR</a> [<i>C</i>entre for - <i>S</i>peech <i>T</i>echnology <i>R</i>esearch] of - <a href="http://www.ed.ac.uk/text.html">University of Edinburgh</a>. -</p> -<p> - Festival offers a full text to speech system with various APIs, as well an - environment for development and research of speech synthesis techniques. - It is written in C++ with a Scheme-based command interpreter for general - control. -</p> -<p> - Besides research into speech synthesis, festival is useful as a stand-alone - speech synthesis program. It is capable of producing clearly understandable - speech from text. -</p> -</a11y-pkg> -<a11y-pkg name="Speech Dispatcher" tag="speech-dispatcher" - url="http://www.freebsoft.org/speechd"> -<p> - Provides a device independent layer for speech synthesis. - It supports various software and hardware speech synthesizers as - backends and provides a generic layer for synthesizing speech and - playing back PCM data via those different backends to applications. -</p> -<p> - Various high level concepts like enqueueing vs. interrupting speech - and application specific user configurations are implemented in a device - independent way, therefore freeing the application programmer from having - to yet again reinvent the wheel. -</p> -</a11y-pkg> - - -<h2><a name="i18nspeech">Internationalised Speech Synthesis</a></h2> -<p> -All the currently available free solutions for software based speech -synthesis seem to share one common deficiency: They are mostly limited to -English, providing only very marginal support for other languages, or in -most cases none at all. -Among all the free software speech synthesizers for Linux, only CMU -Festival supports more than one natural language. CMU Festival can -synthesize English, Spanish and Welsh. German is not -supported. French is not supported. Russian is not supported. When -internationalization and localization are the trends in software and -web services, is it reasonable to require blind people interested in -Linux to learn English just to understand their computer's output and to -conduct all their correspondence in a foreign tongue? -</p> -<p> -Unfortunately, speech synthesis is not really Jane Hacker's favourite -homebrew project. Creating an intelligible software speech -synthesizer involves time-consuming tasks. -Concatenative speech synthesis requires the careful creation of a -phoneme database containing all the possible combinations of sounds -for the target language. -Rules that determine the transformation of the text representation -into individual phonemes also need to be developed and fine-tuned, -usually requiring the division of the stream of characters into -logical groups such as sentences, phrases and words. Such lexical -analysis requires a language-specific lexicon seldom released under a -free license. -</p> -<p> -One of the most promising speech synthesis systems is Mbrola, with -phoneme databases for over several dozen different languages. The synthesis -itself is free software. Unfortunately the phoneme databases are for -non-military and non-commercial use only. We are lacking free phoneme -databases in order to be used in the Debian Operating System. -</p> -<p> -Without a broadly multi-lingual software speech synthesizer, Linux -cannot be accepted by assistive technology providers and people with -visual disabilities. What can we do to improve this? -</p> -<p> -There are basically two approaches possible: -</p> -<ol> -<li>Organize a group of people willing to help in this regard, and -try to actively improve the situation. This might get a bit complicated, -since a lot of specific knowledge about speech synthesis will be required, -which isn't that easy if done via an autodidactic approach. However, this -should not discourage you. If you think you can motivate a group of -people large enough to achieve some improvements, it would be worthwhile -to do.</li> -<li>Obtain funding and hire some institute which already has the -know how to create the necessary phoneme databases, lexica and transformation -rules. This approach has the advantage that it has a better probability -of generating quality results, and it should also achieve some improvements -much earlier than the first approach. Of course, the license under which all -resulting work would be released should be agreed on in advance, and it should -pass the DFSG requirements. The ideal solution would of course -be to convince some university to undergo such a project on their own -dime, and contribute the results to the Free Software community.</li> -</ol> -<p> -Last but not least, it seems most of the commercially successful -speech synthesis products nowadays do no longer use concatenative speech -synthesis, mainly because the sound databases -consume a lot of diskspace. This is not really desireable -for small embedded products, like for instance speech -on a mobile phone. Recently released Free software like <a href="#espeak">eSpeak</a> -seem to try this approach, which might be very worthwhile -to look at. -</p> - - -<h2><a id="emacs" name="emacs">Screen review extensions for Emacs</a></h2> -<a11y-pkg name="Emacspeak" tag="emacspeak" - url="http://emacspeak.sourceforge.net/"> -<p> - A speech output system that will allow someone who cannot see - to work directly on a UNIX system. Once you start Emacs with - Emacspeak loaded, you get spoken feedback for everything you do. Your - mileage will vary depending on how well you can use Emacs. There is nothing - that you cannot do inside Emacs :-). This package includes speech servers - written in tcl to support the DECtalk Express and DECtalk MultiVoice - speech synthesizers. For other synthesizers, look for separate - speech server packages such as Emacspeak-ss or <a href="#eflite">eflite</a>. -</p> -</a11y-pkg> -<a11y-pkg name="speechd-el" tag="speechd-el" - url="http://www.freebsoft.org/speechd-el"> -<p> - Emacs client to speech synthesizers, Braille displays - and other alternative output interfaces. It provides full speech and - Braille output environment for Emacs. It is aimed primarily at - visually impaired users who need non-visual communication with Emacs, - but it can be used by anybody who needs sophisticated speech or other - kind of alternative output from Emacs. -</p> -</a11y-pkg> - - -<h2><a id="console" name="console">Console (text-mode) screen readers</a></h2> - -<p> - A thorough list is available on the - <a href="https://blends.debian.org/accessibility/tasks/console">console screen readers task page</a> -</p> - -<a11y-pkg name="BRLTTY" tag="brltty" url="https://brltty.app/"> -<p> - A daemon which provides access to the Linux console for a blind - person using a soft braille display. - It drives the braille terminal and provides complete screen review - functionality. -</p> -<p> - The Braille devices supported by BRLTTY are listed on the - <a href="https://brltty.app/doc/KeyBindings/#braille-device-bindings"> - BRLTTY device documentation</a> -</p> -<p> - BRLTTY also provides a client/server based infrastructure for applications - wishing to utilize a Braille display. The daemon process listens for - incoming TCP/IP connections on a certain port. A shared object library - for clients is provided in the package - <a href="https://packages.debian.org/libbrlapi">libbrlapi</a>. A static - library, header files and documentation is provided in package - <a href="https://packages.debian.org/libbrlapi-dev">libbrlapi-dev</a>. This - functionality is for instance used by <a href="#gnome-orca">Orca</a> - to provide support for display types which are not yet support by Gnopernicus - directly. -</p> -</a11y-pkg> -<a11y-pkg name="Yasr" tag="yasr" url="http://yasr.sourceforge.net/"> -<p> - A general-purpose console screen reader for GNU/Linux and - other UNIX-like operating systems. The name <q>yasr</q> is an acronym that - can stand for either <q>Yet Another Screen Reader</q> or <q>Your All-purpose - Screen Reader</q>. -</p> -<p> - Currently, yasr attempts to support the Speak-out, DEC-talk, BNS, Apollo, - and DoubleTalk hardware synthesizers. It is also able to communicate with - Emacspeak speech servers and can thus be used with synthesizers not directly - supported, such as <a href="#flite">Festival Lite</a> (via - <a href="#eflite">eflite</a>) or FreeTTS. -</p> -<p> - Yasr works by opening a pseudo-terminal and running a shell, intercepting - all input and output. It looks at the escape sequences being sent and - maintains a virtual <q>window</q> containing what it believes to be on the - screen. It thus does not use any features specific to Linux and can be - ported to other UNIX-like operating systems without too much trouble. -</p> -</a11y-pkg> - - -<h2><a id="gui" name="gui">Graphical User Interfaces</a></h2> -<p> -Accessibility of graphical user interfaces on UNIX platforms has only recently -received a significant upswing with the various development efforts around the -<a href="http://www.gnome.org/">GNOME Desktop</a>, especially the -<a href="https://wiki.gnome.org/Accessibility">GNOME Accessibility Project</a>. -</p> - - -<h2><a id="gnome" name="gnome">GNOME Accessibility Software</a></h2> - -<p> - A thorough list is available on the - <a href="https://blends.debian.org/accessibility/tasks/gnome">Gnome accessibility task page</a> -</p> - -<a11y-pkg name="Assistive Technology Service Provider Interface" tag="at-spi"> -<p> - This package contains the core components of GNOME Accessibility. - It allows Assistive technology providers like screen readers to - query all applications running on the desktop for accessibility - related information as well as provides bridging mechanisms to support - other toolkits than GTK. -</p> -<p> - Bindings to the Python language are provided in package - <a href="https://packages.debian.org/python-at-spi">python-at-spi</a>. -</p> -</a11y-pkg> -<a11y-pkg name="The ATK accessibility toolkit" tag="atk"> -<p> - ATK is a toolkit providing accessibility interfaces for applications or - other toolkits. By implementing these interfaces, those other toolkits or - applications can be used with tools such as screen readers, magnifiers, and - other alternative input devices. -</p> -<p> - The runtime part of ATK, needed to run applications built with it is available - in package <a href="https://packages.debian.org/libatk1.0-0">libatk1.0-0</a>. - Development files for ATK, needed for compilation of programs or toolkits - which use it are provided by package <a href="https://packages.debian.org/libatk1.0-dev">libatk1.0-dev</a>. - Ruby language bindings are provided by package - <a href="https://packages.debian.org/ruby-atk">ruby-atk</a>. -</p> -</a11y-pkg> -<a11y-pkg name="gnome-accessibility-themes" tag="gnome-accessibility-themes"> -<p> - The gnome-accessibility-themes package contains some high accessibility themes - for the GNOME desktop environment, designed for the visually impaired. -</p> -<p> - A total of 7 themes are provided, providing combinations of high, low - or inversed contrast, as well as enlarged text and icons. -</p> -</a11y-pkg> -<a11y-pkg name="gnome-orca" tag="gnome-orca" - url="http://live.gnome.org/Orca"> -<p> - Orca is a flexible and extensible screen reader - that provides access to the graphical desktop via user-customizable - combinations of speech, braille, and/or magnification. Under - development by the Sun Microsystems, Inc., Accessibility Program - Office since 2004, Orca has been created with early input from and - continued engagement with its end users. -</p> -<p> - Orca can use <a href="#speech-dispatcher">Speech Dispatcher</a> for delivering speech - output to the user. <a href="#brltty">BRLTTY</a> is used for braille display - support (and for seamless console and GUI braille review integration). -</p> -</a11y-pkg> - - -<h2><a id="kde" name="kde">KDE Accessibility Software</a></h2> - -<p> - A thorough list is available on the - <a href="https://blends.debian.org/accessibility/tasks/kde">KDE accessibility task page</a> -</p> - -<a11y-pkg name="kmag" tag="kmag"> -<p> - Magnify a part of the screen just as you would use a lens to magnify a - newspaper fine-print or a photograph. This application is useful for - a variety of people: from researchers to artists to web-designers - to people with low vision. -</p> -</a11y-pkg> - - -<h2><a id="input" name="input">Non-standard input methods</a></h2> - -<p> - A thorough list is available on the - <a href="https://blends.debian.org/accessibility/tasks/input">Input methods task page</a> -</p> - -<a11y-pkg name="Dasher" tag="dasher" url="http://www.inference.phy.cam.ac.uk/dasher/"> -<p> - Dasher is an information-efficient text-entry interface, driven by natural - continuous pointing gestures. Dasher is a competitive text-entry system - wherever a full-size keyboard cannot be used - for example, -</p> - <ul> - <li>on a palmtop computer</li> - <li>on a wearable computer</li> - <li>when operating a computer one-handed, by joystick, touchscreen, - trackball, or mouse</li> - <li>when operating a computer with zero hands (i.e., by head-mouse or by - eyetracker).</li> - </ul> -<p> - The eyetracking version of Dasher allows an experienced user to write text - as fast as normal handwriting - 25 words per minute; using a mouse, - experienced users can write at 39 words per minute. -</p> -<p> - Dasher uses a more advanced prediction algorithm than the T9(tm) system - often used in mobile phones, making it sensitive to surrounding context. -</p> -</a11y-pkg> -<a11y-pkg name="Caribou" tag="caribou" url="https://wiki.gnome.org/Projects/Caribou"> -<p> - Caribou is an input assistive technology intended for switch and pointer -users. It provides a configurable on-screen keyboard with scanning mode. -</p> -</a11y-pkg> diff --git a/greek/devel/debian-desktop/Makefile b/greek/devel/debian-desktop/Makefile deleted file mode 100644 index c26323c0c92..00000000000 --- a/greek/devel/debian-desktop/Makefile +++ /dev/null @@ -1 +0,0 @@ -include $(subst webwml/greek,webwml/english,$(CURDIR))/Makefile diff --git a/greek/devel/debian-desktop/index.wml b/greek/devel/debian-desktop/index.wml deleted file mode 100644 index fbc325f5f37..00000000000 --- a/greek/devel/debian-desktop/index.wml +++ /dev/null @@ -1,70 +0,0 @@ -#use wml::debian::template title="Debian on the Desktop" MAINPAGE="true" -#use wml::debian::recent_list -#use wml::debian::translation-check translation="21849af3149d448e7ee39af170c93bee402c4d3a" maintainer="galaxico" - -<link href="$(HOME)/font-awesome.css" rel="stylesheet" type="text/css"> - -<ul class="toc"> -<li><a href="#philosophy">Our Philosophy</a></li> -<li><a href="#help">How you can help</a></li> -<li><a href="#join">Join us</a></li> -</ul> - -<aside> -<p><span class="fas fa-caret-right fa-3x"></span> Debian Desktop is a group of volunteers who want to create the best possible operating system for home and corporate workstation use. Our motto: <q>Software that just works.</q> Our goal: bringing Debian, GNU, and Linux to the mainstream world.</p> -</aside> - -<h2><a id="philosophy">Our Philosophy</a></h2> - -<p> -We recognize that many -<a href="https://wiki.debian.org/DesktopEnvironment">Desktop -Environments</a> exist and will support the use of them – this includes -making sure they work well on Debian. Our goal is to make the graphical -interfaces easy to use for beginners while allowing advanced users and -experts to tweak things if they like. -</p> - -<p> -We will try to ensure that software is configured for the most common -desktop use. For example, the regular user account created during the -installation should have permission to play audio and video, print, -and manage the system through sudo. Also, we would like to keep -<a href="https://wiki.debian.org/debconf">debconf</a> (the Debian -configuration management system) questions to the absolute minimum. -There is no need to present difficult technical details during the -installation. Instead, we will try to ensure that debconf questions -make sense to the users. A novice may not even understand what these -questions are about. An expert, however, is perfectly happy to configure -the dekstop environment after the installation is complete. -</p> - -<h2><a id="help">How you can help</a></h2> - -<p> -We're looking for motivated people who make things happen. You don't have -to be a Debian Developer (DD) to submit patches or make packages. The -core Debian Desktop team will ensure that your work is integrated. So, -here are some things you can do to help: -</p> - -<ul> - <li>Test the default desktop environment (or any of the other desktops) for the upcoming release. Get one of the <a href="$(DEVEL)/debian-installer/">testing images</a> and send feedback to the <a href="https://lists.debian.org/debian-desktop/">debian-desktop mailing list</a>.</li> - <li>Join the <a href="https://wiki.debian.org/DebianInstaller/Team">Debian Installer Team</a> and help to improve the <a href="$(DEVEL)/debian-installer/">debian-installer</a> – the GTK+ frontend needs you.</li> - <li>You can help the <a href="https://wiki.debian.org/Teams/DebianGnome">Debian GNOME Team</a>, the <a href="https://qt-kde-team.pages.debian.net/"> Debian Qt/KDE Maintainers and Debian KDE Extras Team</a>, or the <a href="https://salsa.debian.org/xfce-team/">Debian Xfce Group</a> with packaging, bug fixing, documentation, tests and more.</li> - <li>Help to improve <a href="https://packages.debian.org/debconf">debconf</a> by lowering the priority of questions or removing unnecessary ones from packages. Make the necessary deconf questions easier to understand.</li> - <li>Got some designer skills? Then why not work on the <a href="https://wiki.debian.org/DebianDesktop/Artwork">Debian Desktop Artwork</a>.</li> -</ul> - -<h2><a id="join">Join us</a></h2> - -<aside class="light"> - <span class="fa fa-users fa-4x"></span> -</aside> - -<ul> - <li><strong>Wiki:</strong> Visit our <a href="https://wiki.debian.org/DebianDesktop">DebianDesktop</a> Wiki (some articles may be outdated).</li> - <li><strong>Mailing List:</strong> Discuss with us on the <a href="https://lists.debian.org/debian-desktop/">debian-desktop</a> mailing list.</li> - <li><strong>IRC Channel:</strong> Chat with us on IRC. Join the #debian-desktop channel on <a href="http://oftc.net/">OFTC IRC</a> (irc.debian.org)</li> -</ul> - diff --git a/greek/devel/debian-installer/builds.wml b/greek/devel/debian-installer/builds.wml deleted file mode 100644 index a91f4e1677a..00000000000 --- a/greek/devel/debian-installer/builds.wml +++ /dev/null @@ -1,89 +0,0 @@ -#use wml::debian::template title="Debian-Installer builds" -#use wml::debian::translation-check translation="c1221b640653be886b43ce18e8e72c5516aa770f" maintainer="galaxico" - -<h2>CD builds</h2> - -<p> -There are a number of different builds of the Debian-Installer CD images -that serve different purposes. -</p> -<p> -The most important build is <a href="index">the current official release</a>, currently -included in Debian 6.0. These images are static and unchanging, and are -the ones mostly likely to work for most people. While testing of these -images is still useful, most problems with them are well known by the -team within a few weeks of their release. See the <a href="errata">errata -page</a> for the worst of the known issues. -</p> -<p> -The other most commonly used builds are the daily builds. -These are newer images that need testing in the hopes -of one day becoming an official release. They are just a link to one of the -two types of images described below; which one is linked to depends on -where we are in our release cycle. -<a href="$(HOME)/releases/stable/i386/ch05s04#submit-bug">Installation reports</a> using these images are -very valuable to us. -</p> -<p> -<a href="https://cdimage.debian.org/cdimage/daily-builds/sid_d-i/">The sid_d-i -images</a> are new CD images produced each day. These images -use the version of the installer from the unstable distribution, although -they still install the testing distribution. Typically the daily CD build links point -at these images. -</p> -<p> -<a href="https://cdimage.debian.org/cdimage/daily-builds/jessie_d-i/">The -jessie_d-i images</a> are also produced each day. They use the version of -the installer from testing, and install testing. At release time, one -of these images is picked and becomes the official release image. Near a -release the links to daily CD builds will be switched to point to these -images, so that they can get testing. -</p> -<p> -<a href="https://cdimage.debian.org/cdimage/weekly-builds/i386/iso-cd/">The weekly full CD</a> -and <a href="https://cdimage.debian.org/cdimage/weekly-builds/i386/iso-dvd/">DVD</a> -builds take several days to build, so are -only regenerated once per week. The version of the installer on these -varies, but is generally the version we want to get tested at the current -time. -</p> - -<h2>initrd builds</h2> - -<p> -All the other Debian-Installer images, including netboot, -are collectively known as the <q>initrd images</q>. Again several different -builds are used. -</p> -<p> -As with the CD images, the most important initrd build is -<a href="index">the current official release</a>. -</p> -<p> -The other most commonly used initrd builds are the daily builds. -These images are built approximately once each day by -some Debian-Installer developers, typically on their own personal machines. -They always include the latest version of the installer, from the unstable -distribution. -</p> -<p> -From time to time an official Debian-Installer initrd build will be done, -as part of a release of the <tt>debian-installer</tt> package. These images -are built on the Debian autobuilder network like any other package, and are -placed in the <tt>dists/unstable/main/binary-<arch>/current</tt> -subdirectory. -</p> -<p> -When Debian-Installer is released, one of these official builds is copied -to the <tt>dists/testing/main/binary-<arch>/current</tt> -subdirectory. -</p> - -<h2>Build status page</h2> - -<p> -The status of all of the periodically built images is tracked and collected -on <a href="https://d-i.debian.org/daily-images/build-logs.html">the build -status page</a>. This page can't tell if the images work, only if it was -successfully built. -</p> diff --git a/greek/devel/debian-installer/errata.wml b/greek/devel/debian-installer/errata.wml deleted file mode 100644 index 438897268e4..00000000000 --- a/greek/devel/debian-installer/errata.wml +++ /dev/null @@ -1,66 +0,0 @@ -#use wml::debian::template title="Debian-Installer errata" -#use wml::debian::recent_list -#include "$(ENGLISHDIR)/devel/debian-installer/images.data" -#use wml::debian::translation-check translation="50ddc8fab8f8142c1e8266a7c0c741f9bfe1b23a" maintainer="galaxico" - -<h1>Errata for <humanversion /></h1> - -<p> -This is a list of known problems in the <humanversion /> release of the Debian -Installer. If you do not see your problem listed here, please send us an -<a href="$(HOME)/releases/stable/amd64/ch05s04#submit-bug">installation -report</a> describing the problem. -</p> - -<dl class="gloss"> - <dt>Broken rescue mode with the graphical installer</dt> - <dd>It was discovered during Bullseye RC 1 image testing that - the rescue mode seems broken (<a href="https://bugs.debian.org/987377">#987377</a>). - Additionally, the “Rescue” label in the banner needs to be - adjusted for the Bullseye theme. - <br /> - <b>Status:</b> Fixed in Bullseye RC 2.</dd> - - <dt>amdgpu firmware required for many AMD graphic cards</dt> - <dd>There seems to be a growing need to install amdgpu firmware - (through the non-free <code>firmware-amd-graphics</code> package) - to avoid a black screen when booting the installed system. As of - Bullseye RC 1, even when using an installation image that includes - all firmware packages, the installer doesn't detect the need for - that specific component. See the - <a href="https://bugs.debian.org/989863">umbrella bug report</a> - to keep track of our efforts. - <br /> - <b>Status:</b> Fixed in Bullseye RC 3.</dd> - - <dt>Firmwares required for some sound cards</dt> - <dd>There seems to be a number of sound cards that require loading a - firmware to be able to emit sound. As of Bullseye, the installer is - not able to load them early, which means that speech synthesis during - installation is not possible with such cards. A possible workaround is to - plug another sound card which does not need such firmware. - See the <a href="https://bugs.debian.org/992699">umbrella bug report</a> - to keep track of our efforts.</dd> - - <dt>Desktop installations may not work using CD#1 alone</dt> - <dd>Due to space constraints on the first CD, not all of the - expected GNOME desktop packages fit on CD#1. For a successful - installation, use extra package sources (e.g. a second CD or a - network mirror) or use a DVD instead. <br /> <b>Status:</b> It is - unlikely more efforts can be made to fit more packages on - CD#1. </dd> - - <dt>LUKS2 is incompatible with GRUB's cryptodisk support</dt> - <dd>It was only lately discovered that GRUB has no support for - LUKS2. This means that users who want to use - <tt>GRUB_ENABLE_CRYPTODISK</tt> and avoid a separate, - unencrypted <tt>/boot</tt>, won't be able to do so - (<a href="https://bugs.debian.org/927165">#927165</a>). This - setup isn't supported in the installer anyway, but it would - make sense to at least document this limitation more - prominently, and to have at least the possibility to opt for - LUKS1 during the installation process. - <br /> - <b>Status:</b> Some ideas have been expressed on the bug; cryptsetup maintainers have written <a href="https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html">some specific documentation</a>.</dd> - -</dl> diff --git a/greek/devel/debian-live/Makefile b/greek/devel/debian-live/Makefile deleted file mode 100644 index c26323c0c92..00000000000 --- a/greek/devel/debian-live/Makefile +++ /dev/null @@ -1 +0,0 @@ -include $(subst webwml/greek,webwml/english,$(CURDIR))/Makefile diff --git a/greek/devel/debian-live/index.wml b/greek/devel/debian-live/index.wml deleted file mode 100644 index f9573e9f9c3..00000000000 --- a/greek/devel/debian-live/index.wml +++ /dev/null @@ -1,29 +0,0 @@ -#use wml::debian::template title="Debian Live" NOHEADER="true" -#use wml::debian::translation-check translation="8377a51d59273f2581a58118cb3505bcdc6fce1c" maintainer="galaxico" - -<h1>The Debian Live Project</h1> - -<p>The Debian Live project produces the framework used to build live -systems based on Debian and the <a href="$(HOME)/CD/live/">official Debian Live -images</a> themselves.</p> - -<p>More information can be found at the <a -href="https://wiki.debian.org/DebianLive">Debian Live project wiki -pages</a>.</p> - -<h2>Contacting the team</h2> - -<p>You can reach the Debian Live team in one of the following ways:</p> -<ul> -<li>Bugs should be reported in the <a href="https://bugs.debian.org/">\ -Debian Bug Tracking System</a> against the appropriate package (e.g. -<a href="https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=live-wrapper">live-wrapper</a> or -one of the other -<a href="https://qa.debian.org/developer.php?login=debian-live%40lists.debian.org&comaint=yes">\ -packages maintained by the Debian Live Project</a>). -<li>You can send an email to the <a href="https://lists.debian.org/debian-live/">debian-live mailing list</a> -and use the archives to learn more about our activities. -<li>Team members and users are at times available on our -<a href="irc://irc.debian.org/debian-live">IRC channel</a>. -If you don't get a useful response, try our mailing list instead. -</ul> diff --git a/greek/devel/debian-med/Makefile b/greek/devel/debian-med/Makefile deleted file mode 100644 index c26323c0c92..00000000000 --- a/greek/devel/debian-med/Makefile +++ /dev/null @@ -1 +0,0 @@ -include $(subst webwml/greek,webwml/english,$(CURDIR))/Makefile diff --git a/greek/devel/debian-med/index.wml b/greek/devel/debian-med/index.wml deleted file mode 100644 index c00576bd355..00000000000 --- a/greek/devel/debian-med/index.wml +++ /dev/null @@ -1,110 +0,0 @@ -#use wml::debian::template title="Debian Med" -#use wml::debian::recent_list -#use wml::debian::translation-check translation="b9967d1f4d930716e9646a92bda776ced3c44cce" maintainer="galaxico" - -<h2>Project description</h2> - -<p>Debian Med is a - "<a href="https://blends.debian.org/blends/">Debian Pure Blend</a>" - with the aim to - develop Debian into an operating - system that is particularly well fit for the requirements for medical - practice and biomedical research. - The goal of Debian Med is a complete free and open system for all tasks in medical - care and research. To achieve this goal Debian Med integrates related - free and open source software for medical imaging, bioinformatics, - clinic IT infrastructure, and others within Debian OS. -</p> - - -<p>Debian Med contains a set of metapackages that declare dependencies on - other Debian packages, and that way the complete system is prepared for - solving particular tasks. - The best overview about Debian Med is given - at the <a href="https://blends.debian.org/med/tasks/">tasks page</a>. -</p> - -<p>For a more in-depth discussion, - <a href="https://people.debian.org/~tille/talks/">several talks about - Debian Med and Debian Pure Blends in general</a> - are available as slides, partly with video recording. -</p> - - -<h2>Contact and developer information</h2> - -<p> -The <a href="mailto:debian-med@lists.debian.org">Debian Med mailing -list</a> is the central point of communication -for Debian Med. It serves as a forum for potential, as well as current, -users of the Debian system who want to use their computer for -medical tasks. Additionally, it is used to coordinate development -efforts around the various topics of Medicine. You can subscribe to -and unsubscribe from it using the -<a href="https://lists.debian.org/debian-med/">list web page</a>. -You will also find the list archives on that page. -</p> -<p> -Important places for developer information: -</p> -<ol> - <li><a href="https://wiki.debian.org/DebianMed">The Wiki page</a></li> - <li><a href="https://blends.debian.org/med/">The Blends page</a></li> - <li>The <a href="https://med-team.pages.debian.net/policy/">Debian Med policy</a> which explains packaging rules in the team</li> - <li><a href="https://salsa.debian.org/med-team/">Git repositories of Debian Med packages on Salsa</a></li> -</ol> - -<h2>Included software projects</h2> - -The <a href="https://blends.debian.org/blends">Debian Pure Blends</a> system -provides an autogenerated overview of all included software of a Blend. -Just have a look at the so called -<b><a href="https://blends.debian.org/med/tasks/">tasks pages of -Debian Med</a></b> to learn about all included software and projects which -are on our todo list for inclusion into Debian. - - -<h2>Project goals</h2> - -<ul> - <li>Build a solid software base for medical health care with emphasis on easy - installation, easy maintenance and security.</li> - <li>Encourage the co-operation of authors of different software projects - with similar goals.</li> - <li>Test suite for easy evaluation of the quality of medical software.</li> - <li>Provide information and documentation of medical software.</li> - <li>Help upstream authors to get their products packaged for - Debian.</li> - <li>Show commercial software companies the strengths of a solid base - system and make them consider to port their software to Linux or - even to switch to Open Source.</li> -</ul> - - -<h2>What can I do to help?</h2> - -<p> - There is a <a href="https://wiki.debian.org/DebianMedTodo">Wiki page containing - a list of things</a> which can be done to help the project. -</p> - -<h2>Marketing & PR</h2> - -<p>Once we have something to show for this project, and indeed even in - the formative stages of this project, we are being watched by the - eyes of the world. We will necessarily want to work with - press@debian.org to get the word out and to help give Debian and - this project the kind of exposure we want. For this purpose we will - build a collection of slides of talks about Debian Med. -</p> - - -<h2>Links</h2> - -<ul> - <li>Debian Med is working closely together with - <a href="http://nebc.nerc.ac.uk/tools/bio-linux/bio-linux-6.0">Bio-Linux</a>. - While Bio-Linux is based on Ubuntu LTS releases the packages of biologic - scope are maintained inside Debian by the Debian Med team. - </li> -</ul> diff --git a/greek/devel/developers.loc.wml b/greek/devel/developers.loc.wml deleted file mode 100644 index fa113ad1be9..00000000000 --- a/greek/devel/developers.loc.wml +++ /dev/null @@ -1,58 +0,0 @@ -#use wml::debian::template title="Developer Locations" MAINPAGE="true" -#use wml::debian::recent_list -#use wml::debian::translation-check translation="bd2e76d96db915ccd0dee367a373417db7422565" maintainer="galaxico" - -<link href="$(HOME)/font-awesome.css" rel="stylesheet" type="text/css"> - -<aside> -<p><span class="fas fa-caret-right fa-3x"></span> Where are the Debian Developers (DD) located? If a DD has specified the home coordinates in the developer database, it's visible in our World Map.</p> -</aside> - -<p> -The map below was generated from an anonymized <a -href="developers.coords">list of developer coordinates</a> using the -program <a href="https://packages.debian.org/stable/graphics/xplanet"> -xplanet</a>. -</p> - -<img src="developers.map.jpeg" alt="World Map"> - -<h2>How to add your Coordinates</h2> - -<p> -If you would like to add your coordinates to your database entry, log in -to the <a href="https://db.debian.org">Debian Developers' Database</a> -and modify your entry. If you don't know the coordinates of your home -town, you can use <a href="https://www.openstreetmap.org">OpenStreetMap</a> to look -them up. Search for your city and select the direction arrows next to the -search field. Drag the green marker to the OSM map, and the coordinates -will appear in the <em>From</em> field. -</p> - -<p>The format for coordinates is one of the following:</p> - -<dl> - <dt>Decimal Degrees</dt> - <dd>The format is <code>+-DDD.DDDDDDDDDDDDDDD</code>. Programs like - Xearth and many other positioning web sites use it. The precision is - limited to 4 or 5 decimals.</dd> - <dt>Degrees Minutes (DGM)</dt> - <dd>The format is <code>+-DDDMM.MMMMMMMMMMMMM</code>. It's not - arithmetic, but a packed representation of two separate units: degrees - and minutes. This output is common with some types of handheld GPS - devices and NMEA format GPS messages.</dd> - <dt>Degrees Minutes Seconds (DGMS)</dt> - <dd>The format is <code>+-DDDMMSS.SSSSSSSSSSS</code>. Like DGM, it's - not arithmetic, but a packed representation of three separate units: - degrees, minutes, and seconds. This output is typically derived - from web sites which give 3 values for each position. For example, - <code>34:50:12.24523 North</code> might be the given position, and in - DGMS it would be <code>+0345012.24523</code>.</dd> -</dl> - -<p> -<strong>Please note:</strong> <code>+</code> is North for latitude, -<code>+</code> is East for longitude. It's important to specify enough -leading zeros to dis-ambiguate the format being used if your position -is less than 2 degrees from a zero point. -</p> diff --git a/greek/devel/dmup.1.1.1.wml b/greek/devel/dmup.1.1.1.wml deleted file mode 100644 index d3ecf5a5126..00000000000 --- a/greek/devel/dmup.1.1.1.wml +++ /dev/null @@ -1,337 +0,0 @@ -#use wml::debian::template title="Debian Machine Usage Policies" NOHEADER=yes -#use wml::debian::translation-check translation="b8114b588961778dbd04974c1464a2f388a90c28" maintainer="galaxico" - -<h2>Debian Machine Usage Policies</h2> - -<p>This is the historical version 1.1.1 of the <i>Debian Machine Usage -Policies</i>, which was superseded by the <a href="dmup">current -version 1.1.2</a>, as announced <a -href="https://lists.debian.org/debian-devel-announce/2010/05/msg00001.html">May -9th, 2010</a>.</p> - -<ol> -<li><strong>Introduction</strong><br> - -This document describes the policies for using -<a href="https://db.debian.org/machines.cgi">Debian machines</a> and -all rules surrounding those. - -<p>In short: -<ul> -<li>Don't by any wilful, deliberate, reckless or unlawful act interfere - with the work of another developer or jeopardize the integrity of data - networks, computing equipment, systems programs, or other stored - information. - -<li>Don't use Debian Facilities for private financial gain or for - commercial purposes, including consultancy or any other work outside - the scope of official duties or functions for the time being, without - specific authorization to do so. - -<li>Don't use Debian Facilities for unlawful activities, including, but - not limited to, software piracy. -</ul> - -<p>This document contains two parts: policies and guidelines. The rules -in the policies are binding and may not be violated. The guidelines -specify rules that may be violated if necessary but we would rather -one did not. - - -<li><strong>General statements</strong><br> - -<ol> -<li> Privilege<br> -Access to Debian Facilities is a privilege, not a right or a -commercial service, and we reserve the right to revoke this privilege -at any time, without prior notice. An explanation will be given within -48 hours. - -<li> Guarantees<br> -There is no guarantee of service. Although we will do our best to assure -that everything functions perfectly, we can't give any guarantees. - -<li> Privacy<br> -If necessary to keep machines working properly the DSA is allowed to edit -user files. (for example modifying .forward files to break mail loops.) - -<li> Used abbreviations<br> - <ul> - <li>DSA - Debian Systems Administration - <li>DMUP - Debian Machine Usage Policy (this document) - <li>DPL - Debian Project Leader - </ul> -</ol> - -<li><strong>Penalties</strong><br> - -If someone violates the rules set in this document they will be subjected -to a penalty. The penalty depends on the number of previous violations -and the offense involved. - -<ol> -<li> First offense<br> - -<ol> -<li>The accounts of the offender will be suspended and access will - not be available. - -<li>The offender will be required to contact the Debian Systems Administration - and convince us that there will be no further breaches of the DMUP by the - offender. - -<li>If the offender fails to contact the DSA within 14 days, the account will - be terminated and the offender expelled from the Debian project. If the - offender has announced they will be on vacation in this time frame this - period will be extended with the announced duration of the vacation. - -<li>If the offender is expelled from the project they can register to become - a maintainer again after a period of a month. The offense will remain - on record. -</ol> - - -<li> Second offense<br> - -<ol> -<li>The offender's accounts will be suspended immediately and the - offender expelled from the project. -<li>If the offender does not file for an appeal within the designated - time frame the account is terminated. - -<li>The offender is prohibited from registering as a Debian maintainer - again. -</ol> - - -<li> Publication<br> - -<ol> -<li>The offense and the penalty will be announced to Debian developers only. - -<li>Should it, in the sole opinion of the Debian project leader, be considered - necessary, then a public announcement will be made. This can include - the offender's identity. -</ol> - - -<li> Appeal<br> - -<ol> -<li>If the offender does not agree with the decision made by the DSA they can - appeal to the developers. This is only possible in the 14 days directly - following the day the offender was informed of the sentence. This is - done using the procedure as detailed in section 4.2 of the Debian - constitution. - -<li>During the time the appeal is processed the account will remain suspended. -</ol> -</ol> - - -<li><strong>The policies</strong><br> - -This section lists the policies. This list is not and cannot be comprehensive. - - -<dl> -<dt>Disk usage: - -<dd>All machines run a /tmp cleanup daemon and expire files after a week. -Some machines have /scratch partitions specifically for storing large -data sets without fear of them being erased. If you receive an email -notification that your homedir is large and that we need more space then -please promptly take action. The DSA's may find it necessary to clean up -exceptionally large space users without warning. - -<dt>Shell: - -<dd>Please use ssh/scp if at all possible rather than less secure alternatives -(rsh, telnet or FTP). - -<p>Idle connections are killed after an hour; this is easy to bypass, -but please don't do so without good cause. - -<p>Mirroring via any private means any portion of the public archives from -the private servers is strictly forbidden without the prior consent of the -residing Mirror Master. Developers are free to use any publicly available -forms of access. - -<dt>Processes: - -<dd>Do not run any long running process without the permission of the DSA's. -Running servers of any sort (this includes IRC bots) without prior permission -from the DSA's is also forbidden. Avoid running processes that are abusive in -CPU or memory. If necessary the DSA's will reap up such processes without -warning. - - -<dt>WWW pages: - -<dd>In general, web space on Debian machines is provided for the purpose of -communicating ideas and files related to the project, or to the Free -Software community in general. Private 'vanity' pages on Debian machines -are discouraged. - -<p>Commercial web pages are not permitted. - -<p>You are responsible for the content of your WWW pages, including -obtaining the legal permission for any works they include and ensuring -that the contents of these pages do not violate the laws that apply to -the location of the server. - -<p>You are responsible for and accept responsibility for any defamatory, -confidential, secret or other proprietary material available via your -WWW pages. - -<p>You may not advertise your WWW pages, or cause another person to -advertise it, by techniques that would be classified as abuse if they -were carried out from a Debian Account. This includes, but is not -limited to, bulk emailing and excessive news posting. Such action may -be treated under the appropriate DMUP as if it had been done from the -Account, or as a violation of this DMUP or both. - -<dt>Mail/News: - -<dd>Using Debian machines for reading mail is OK, please choose a lightly -loaded machine [ie not master]. We do not support the use of mail download -methods such as POP or IMAP, use your ISP's mail server and forwarding. As -with web pages incoming mail is generally encouraged to be of a Free -Software nature or related to the project somehow. The DSA's may find it -necessary to compress, relocate or erase mail without warning. -</dl> - -<p>If a Developer becomes unreachable for a prolonged time their accounts, -data and mail forwarding/filtering/etc may be disabled until they -reappear. - - -<p>Don't use Debian facilities in a manner which constitutes net abuse. -Debian does not have any Usenet news servers. It may be that some of the -Debian machines have access to such a news server, but their use through -Debian machines is strictly forbidden. - -<p>Examples of what we consider net abuse: - -<ul> -<li><em>Chain Letters and Ponzi Pyramid-Selling Schemes</em><br> - - Such messages work (or rather, don't work) in much the same - way as their paper-based cousins. The most common example of - this in email is MAKE-MONEY-FAST. In addition to being a - waste of resources, such messages are illegal in certain - countries. - -<li><em>Unsolicited Commercial Email (UCE)</em><br> - - Unsolicited Commercial Email is advertising material - received by email without the recipient either requesting - such information or otherwise expressing an interest in the - material advertised. - - <p>Since many Internet users use a dial-up connection and pay - for their online time, it costs them money to receive - email. Receipt of unsolicited commercial advertising - therefore costs them money and is particularly unwelcome. - - <p>It should be noted that a user has not expressed an interest - by the mere act of posting a news article in any particular - newsgroup, unless of course they have made a specific - request for information to be emailed to them. - -<li><em>Unsolicited Bulk Email (UBE)</em><br> - - Similar to the above UCE but not attempting to sell - anything. Its sole purpose is usually to annoy. - -<li><em>Forged headers and / or Addresses</em><br> - - Forging headers or messages means sending mail such that its - origin appears to be another user or machine, or a - non-existent machine. - - <p>It is also forgery to arrange for any replies to the mail to - be sent to some other user or machine. - - <p>However, in either case, if prior permission has been - granted to you by the other user or the administrators of - the other machine, then there is no problem, and of course - "null" reverse paths can be used as defined in the relevant - RFCs. - -<li><em>Mail Bombing</em><br> - - Mail bombing is the sending of multiple emails, or one large - email, with the sole intent of annoying and / or seeking - revenge on a fellow Internet user. It is wasteful of shared - Internet resource as well as serving no value to the - recipient. - - <p>Due to the time taken to download it, sending long email to - sites without prior agreement can amount to denial of - service, or access to email at the receiving site. Note that - if binary attachments are added to mail this may increase - the size considerably. If prior arrangement has not been - made, the mail will be extremely unwelcome. - -<li><em>Denial of Service attacks</em><br> - - Denial of Service is any activity designed to prevent a - specific host on the Internet making full and effective use - of their facilities. This includes, but is not limited to: - - <ul> - <li>Mail bombing an address in such a way to make their - Internet access impossible, difficult, or costly. - <li>Opening an excessive number of mail connections to the - same host. - <li>Intentionally sending email designed to damage the - receiver's systems when interpreted; for example, sending - malicious programs or viruses attached to an email. - <li>Using a smarthost or SMTP relay without authorization to do so. - </ul> - -<li><em>Mailing List Subscriptions</em><br> - - You must not subscribe anyone, other than a user on your own - host, to a mail list or similar service without their - permission. - -<li><em>Illegal Content</em><br> - - You must not send via email any item which it is illegal to - send or possess. - -<li><em>Breach of Copyright or Intellectual Property</em><br> - - You must not send (via email) or post Copyright material or - Intellectual Property unless you have permission to do so. - -<li><em>Binary Postings to non-Binary Groups</em><br> - - Outside of the alt.binaries... and alt.pictures... newsgroup - hierarchies, the posting of encoded binary data is - considered most unwelcome. The majority of Usenet sites and - readers do not have the capability for selective - transmission of articles (kill-filing) and such posts can - result in a significant amount of resources being tied up - and wasted in the transmission process, and as such can be - considered as a denial of service attack on multiple - recipients. [Example] - -<li><em>Excessive Cross-Posting</em><br> - - Simply put, this form of unacceptable behavior occurs when - the same article is cross-posted to a large number of - unrelated newsgroups. - -<li><em>Excessive Multi-Posting</em><br> - - Simply put, this form of unacceptable behavior occurs when - a substantively similar (perhaps differing only in Subject - header) article is posted to a large number of unrelated - newsgroups. -</ul> - - -</ol> diff --git a/greek/devel/dmup.wml b/greek/devel/dmup.wml deleted file mode 100644 index 50d3264bb63..00000000000 --- a/greek/devel/dmup.wml +++ /dev/null @@ -1,341 +0,0 @@ -#use wml::debian::template title="Debian Machine Usage Policies" NOHEADER=yes -#use wml::debian::translation-check translation="b8114b588961778dbd04974c1464a2f388a90c28" maintainer="galaxico" - -<h2>Debian Machine Usage Policies</h2> -<p> -Version 1.1.2<br> -This version of the Debian Machine Usage Policies becomes effective on -July 4th, 2010 and supersedes all previous <a -href="dmup.1.1.1">versions</a>. It was <a -href="https://lists.debian.org/debian-devel-announce/2010/05/msg00001.html">announced -on May 9th, 2010</a>.</p> - -<ol> -<li><strong>Introduction</strong><br> - -This document describes the policies for using -<a href="https://db.debian.org/machines.cgi">Debian machines</a> and -all rules surrounding those. - -<p>In short: -<ul> -<li>The Debian Systems Administration Team will do whatever is necessary - to keep all machines and services working and running in a secure - fashion. - -<li>Don't by any wilful, deliberate, reckless or unlawful act interfere - with the work of another developer or jeopardize the integrity of data - networks, computing equipment, systems programs, or other stored - information. - -<li>Don't use Debian Facilities for private financial gain or for - commercial purposes, including consultancy or any other work outside - the scope of official duties or functions for the time being, without - specific authorization to do so. - -<li>Don't use Debian Facilities for unlawful activities, including, but - not limited to, software piracy. -</ul> - -<p>This document contains two parts: policies and guidelines. The rules -in the policies are binding and may not be violated. The guidelines -specify rules that may be violated if necessary but we would rather -one did not. - - -<li><strong>General statements</strong><br> - -<ol> -<li> Used abbreviations<br> - <ul> - <li>DSA - Debian Systems Administration - <li>DMUP - Debian Machine Usage Policy (this document) - <li>DPL - Debian Project Leader - <li>DAM - Debian Account Managers - </ul> - -<li> Privilege<br> -Access to Debian Facilities is a privilege, not a right or a -commercial service, and DSA reserves the right to revoke this privilege -at any time, without prior notice. An explanation will be given within -48 hours. - -<li> Guarantees<br> -There is no guarantee of service. Although DSA will do its best to assure -that everything functions perfectly, they can't give any guarantees. - -<li> Privacy<br> -If necessary to keep machines working properly the DSA is allowed to edit -user files. (for example modifying .forward files to break mail loops.) -</ol> - -<li><strong>Penalties</strong><br> - -If someone violates the rules set in this document they will be subjected -to a penalty. The penalty depends on the number of previous violations -and the offense involved. - -<ol> -<li> First offense<br> - -<ol> -<li>The accounts of the offender will be suspended and access will - not be available. - -<li>The offender will be required to contact DSA and convince them - that there will be no further breaches of the DMUP by the offender. - -<li>If the offender fails to contact DSA within 14 days, DSA - will suspend the corresponding account and propose to DAM the - expulsion of the offender from the Debian project. If the offender - has announced they will be on vacation in this time frame, - this period will be extended with the announced duration of - the vacation. -<li>If the offender is expelled from the project they can register to become - a maintainer again after a period of a month. The offense will remain - on record. -</ol> - - -<li> Second offense<br> - -<ol> -<li>The offender's accounts will be suspended immediately and - DSA will propose to DAM the expulsion of the offender from - the Debian project. -<li>If the offender does not file for an appeal within the designated - time frame the account is terminated. - -</ol> - - -<li> Publication<br> - -<ol> -<li>The offense and the penalty will be announced to Debian developers only. - -<li>Should it, in the sole opinion of the Debian project leader, be considered - necessary, then a public announcement will be made. This can include - the offender's identity. -</ol> - - -<li> Appeal<br> - -<ol> -<li>If the offender does not agree with the decision made by DSA they - can appeal to the developers. This is only possible in the 14 days directly - following the day the offender was informed of the sentence. This is - done using the procedure as detailed in section 4.2 of the Debian - constitution. - -<li>During the time the appeal is processed the account will remain suspended. -</ol> -</ol> - - -<li><strong>The policies</strong><br> - -This section lists the policies. This list is not and cannot be comprehensive. - - -<dl> -<dt>Disk usage: - -<dd>All machines run a /tmp cleanup daemon and expire files after a week. -Some machines have /scratch partitions specifically for storing large -data sets without fear of them being erased. If you receive an email -notification that your homedir is large and that more free space is -needed then please promptly take action. DSA may find it necessary to -clean up without warning. - -<dt>Shell: - -<dd>Please use ssh/scp if at all possible rather than less secure alternatives -(rsh, telnet or FTP). - -<p>Idle connections are killed after an hour; this is easy to bypass, -but please don't do so without good cause. - -<p>Mirroring via any private means any portion of the public archives from -the private servers is strictly forbidden without the prior consent of the -residing Mirror Master. Developers are free to use any publicly available -forms of access. - -<dt>Processes: - -<dd>Do not run any long running process without the permission of DSA. -Running servers of any sort (this includes IRC bots) without prior -permission from DSA is also forbidden. Avoid running processes that are -abusive in CPU or memory. If necessary DSA will clean up such processes -without warning. - -<dt>WWW pages: - -<dd>In general, web space on Debian machines is provided for the purpose of -communicating ideas and files related to the project, or to the Free -Software community in general. Private 'vanity' pages on Debian machines -are discouraged. - -<p>Commercial web pages are not permitted. - -<p>You are responsible for the content of your WWW pages, including -obtaining the legal permission for any works they include and ensuring -that the contents of these pages do not violate the laws that apply to -the location of the server. - -<p>You are responsible for and accept responsibility for any defamatory, -confidential, secret or other proprietary material available via your -WWW pages. - -<p>You may not advertise your WWW pages, or cause another person to -advertise it, by techniques that would be classified as abuse if they -were carried out from a Debian Account. This includes, but is not -limited to, bulk emailing and excessive news posting. Such action may -be treated under the appropriate DMUP as if it had been done from the -Account, or as a violation of this DMUP or both. - -<dt>Mail/News: - -<dd>Using Debian machines for reading mail is OK, please choose a -lightly loaded machine. We do not support the use of mail download -methods such as POP or IMAP, use your ISP's mail server and forwarding. -As with web pages incoming mail is generally encouraged to be of a Free -Software nature or related to the project somehow. DSA may find it -necessary to compress, relocate or erase mail without warning. -</dl> - -<p>If a Developer becomes unreachable for a prolonged time, their -accounts, data and mail forwarding/filtering/etc may be disabled until -they reappear. - - -<p>Don't use Debian facilities in a manner which constitutes net abuse. -Debian does not have any Usenet news servers. It may be that some of the -Debian machines have access to such a news server, but their use through -Debian machines is strictly forbidden. - -<p>Examples of what DSA considers net abuse: - -<ul> -<li><em>Chain Letters and Ponzi Pyramid-Selling Schemes</em><br> - - Such messages work (or rather, don't work) in much the same - way as their paper-based cousins. The most common example of - this in email is MAKE-MONEY-FAST. In addition to being a - waste of resources, such messages are illegal in certain - countries. - -<li><em>Unsolicited Commercial Email (UCE)</em><br> - - Unsolicited Commercial Email is advertising material - received by email without the recipient either requesting - such information or otherwise expressing an interest in the - material advertised. - - <p>Since many Internet users use a dial-up connection and pay - for their online time, it costs them money to receive - email. Receipt of unsolicited commercial advertising - therefore costs them money and is particularly unwelcome. - - <p>It should be noted that a user has not expressed an interest - by the mere act of posting a news article in any particular - newsgroup, unless of course they have made a specific - request for information to be emailed to them. - -<li><em>Unsolicited Bulk Email (UBE)</em><br> - - Similar to the above UCE but not attempting to sell - anything. Its sole purpose is usually to annoy. - -<li><em>Forged headers and / or Addresses</em><br> - - Forging headers or messages means sending mail such that its - origin appears to be another user or machine, or a - non-existent machine. - - <p>It is also forgery to arrange for any replies to the mail to - be sent to some other user or machine. - - <p>However, in either case, if prior permission has been - granted to you by the other user or the administrators of - the other machine, then there is no problem, and of course - "null" reverse paths can be used as defined in the relevant - RFCs. - -<li><em>Mail Bombing</em><br> - - Mail bombing is the sending of multiple emails, or one large - email, with the sole intent of annoying and / or seeking - revenge on a fellow Internet user. It is wasteful of shared - Internet resource as well as serving no value to the - recipient. - - <p>Due to the time taken to download it, sending long email to - sites without prior agreement can amount to denial of - service, or access to email at the receiving site. Note that - if binary attachments are added to mail this may increase - the size considerably. If prior arrangement has not been - made, the mail will be extremely unwelcome. - -<li><em>Denial of Service attacks</em><br> - - Denial of Service is any activity designed to prevent a - specific host on the Internet making full and effective use - of their facilities. This includes, but is not limited to: - - <ul> - <li>Mail bombing an address in such a way to make their - Internet access impossible, difficult, or costly. - <li>Opening an excessive number of mail connections to the - same host. - <li>Intentionally sending email designed to damage the - receiver's systems when interpreted; for example, sending - malicious programs or viruses attached to an email. - <li>Using a smarthost or SMTP relay without authorization to do so. - </ul> - -<li><em>Mailing List Subscriptions</em><br> - - You must not subscribe anyone, other than a user on your own - host, to a mail list or similar service without their - permission. - -<li><em>Illegal Content</em><br> - - You must not send via email any item which it is illegal to - send or possess. - -<li><em>Breach of Copyright or Intellectual Property</em><br> - - You must not send (via email) or post Copyright material or - Intellectual Property unless you have permission to do so. - -<li><em>Binary Postings to non-Binary Groups</em><br> - - Outside of the alt.binaries... and alt.pictures... newsgroup - hierarchies, the posting of encoded binary data is - considered most unwelcome. The majority of Usenet sites and - readers do not have the capability for selective - transmission of articles (kill-filing) and such posts can - result in a significant amount of resources being tied up - and wasted in the transmission process, and as such can be - considered as a denial of service attack on multiple - recipients. [Example] - -<li><em>Excessive Cross-Posting</em><br> - - Simply put, this form of unacceptable behavior occurs when - the same article is cross-posted to a large number of - unrelated newsgroups. - -<li><em>Excessive Multi-Posting</em><br> - - Simply put, this form of unacceptable behavior occurs when - a substantively similar (perhaps differing only in Subject - header) article is posted to a large number of unrelated - newsgroups. -</ul> - - -</ol> diff --git a/greek/devel/extract_key.wml b/greek/devel/extract_key.wml deleted file mode 100644 index 6ad24ba72ef..00000000000 --- a/greek/devel/extract_key.wml +++ /dev/null @@ -1,6 +0,0 @@ -#use wml::debian::template title="Extracting a developer's PGP/GPG Key" -#use wml::debian::translation-check translation="e0e8489e695219a95c1630c9211978a2eaee0637" maintainer="galaxico" - -<p>Search for the developer in the -<a href="https://db.debian.org/">Developers' Database</a> and then click -on the “PGP/GPG fingerprint” link(s) once you have found them. diff --git a/greek/devel/index.wml b/greek/devel/index.wml deleted file mode 100644 index 3286702c182..00000000000 --- a/greek/devel/index.wml +++ /dev/null @@ -1,255 +0,0 @@ -#use wml::debian::template title="Debian Developers' Corner" MAINPAGE="true" -#use wml::debian::recent_list -#use wml::debian::translation-check translation="9a3deb4236c92e083ea1e494362dc1ff242f6a8c" maintainer="galaxico" - -<link href="$(HOME)/font-awesome.css" rel="stylesheet" type="text/css"> - -<aside> -<p><span class="fas fa-caret-right fa-3x"></span> Though all information on this page and all links to other pages are publicly available, this site is primarily aimed at Debian developers.</p> -</aside> - -<ul class="toc"> -<li><a href="#basic">Basic</a></li> -<li><a href="#packaging">Packaging</a></li> -<li><a href="#workinprogress">Work in Progress</a></li> -<li><a href="#projects">Projects</a></li> -<li><a href="#miscellaneous">Miscellaneous</a></li> -</ul> - -<div class="row"> - - <!-- left column --> - <div class="column column-left" id="basic"> - <div style="text-align: center"> - <span class="fa fa-users fa-3x" style="float:left;margin-right:5px;margin-bottom:5px;"></span> - <h2><a id="basic">General Information</a></h2> - <p>A list of current developers and maintainers, how to join the project, and links to the developers' database, the constitution, the voting process, releases, and architectures.</p> - </div> - - <div style="text-align: left"> - <dl> - <dt><a href="$(HOME)/intro/organization">Debian Organization</a></dt> - <dd>Over one thousand volunteers are part of the Debian project. This page explains Debian's organizational structure, lists teams and their members as well as contact addresses.</dd> - <dt><a href="$(HOME)/intro/people">People behind Debian</a></dt> - <dd><a href="https://wiki.debian.org/DebianDeveloper">Debian Developers (DD)</a> (full members of the Debian project) and <a href="https://wiki.debian.org/DebianMaintainer">Debian Maintainers (DM)</a>, contribute to the project. Please have a look at the <a href="https://nm.debian.org/public/people/dd_all/">list of Debian Developers</a> and the <a href="https://nm.debian.org/public/people/dm_all/">list of Debian Maintainers</a> to find out more about the people involved. We also have a <a href="developers.loc">world map of Debian developers</a>.</dd> - <dt><a href="join/">How to join Debian</a></dt> - <dd>Would you like to contribute and join the project? We're always looking for new developers or free software enthusiasts with technical and non-technical skills. For more information, please visit this page.</dd> - <dt><a href="https://db.debian.org/">Developer Database</a></dt> - <dd>Some information in this database is accessible to everybody, some information only to developers who have logged in. The database contains information such as <a href="https://db.debian.org/machines.cgi">project machines</a> and developers' GnuPG keys. - To extract a developer's key click on the “PGP/GPG fingerprint” link(s) once you have found them. - Developers can <a href="https://db.debian.org/password.html">change their password</a> and set up <a href="https://db.debian.org/forward.html">mail forwarding</a> for their Debian account. If you're planning to use one of the Debian machines, please make sure to read the <a href="dmup">Debian Machine Usage Policies</a>.</dd> - <dt><a href="constitution">The Constitution</a></dt> - <dd>This document describes the organizational structure for formal decision-making in the project. - </dd> - <dt><a href="$(HOME)/vote/">Voting Information</a></dt> - <dd>How we elect our leaders, choose our logos and how we vote in general.</dd> - <dt><a href="$(HOME)/releases/">Releases</a></dt> - <dd>This page lists current releases (<a href="$(HOME)/releases/stable/">stable</a>, <a href="$(HOME)/releases/testing/">testing</a>, and <a href="$(HOME)/releases/unstable/">unstable</a>) and contains an index of old releases and their codenames.</dd> - <dt><a href="$(HOME)/ports/">Different Architectures</a></dt> - <dd>Debian runs on many different architectures. This page collects information about various Debian ports, some based on the Linux kernel, others based on the FreeBSD, NetBSD and Hurd kernels.</dd> - - </dl> - </div> - - </div> - - <!-- right column --> - <div class="column column-right" id="software"> - <div style="text-align: center"> - <span class="fa fa-code fa-3x" style="float:left;margin-right:5px;margin-bottom:5px;"></span> - <h2><a id="packaging">Packaging</a></h2> - <p>Links to our policy manual and other documents related to the Debian policy, procedures and other resources for Debian developers, and the new maintainers' guide.</p> - </div> - - <div style="text-align: left"> - <dl> - <dt><a href="$(DOC)/debian-policy/">Debian Policy Manual</a></dt> - <dd>This manual describes the policy requirements for the Debian distribution. This includes the structure and contents of the Debian archive, several design issues of the operating system as well as technical requirements which each package must satisfy to be included in the distribution. - - <p>In short, you <strong>need</strong> to read it.</p> - </dd> - </dl> - - <p>There are several other documents related to the policy that you might be - interested in:</p> - - <ul> - <li><a href="https://wiki.linuxfoundation.org/lsb/fhs/">Filesystem Hierarchy Standard</a> (FHS) - <br />The FHS defines the directory structure - and directory contents (location of files); - compliance with version 3.0 is mandatory (see <a - href="https://www.debian.org/doc/debian-policy/ch-opersys.html#file-system-hierarchy">chapter - 9</a> of the Debian Policy Manual).</li> - <li>List of <a href="$(DOC)/packaging-manuals/build-essential">build-essential packages</a> - <br />You are expected to have these packages if you want to - compile software, build a package or a set of packages. You don't - have to include them in <code>Build-Depends</code> line when <a - href="https://www.debian.org/doc/debian-policy/ch-relationships.html">declaring - relationships</a> between packages.</li> - <li><a href="$(DOC)/packaging-manuals/menu-policy/">Menu system</a> - <br />Debian's structure of menu entries; please check the - <a href="$(DOC)/packaging-manuals/menu.html/">menu system</a> - documentation as well.</li> - <li><a href="$(DOC)/packaging-manuals/debian-emacs-policy">Emacs Policy</a></li> - <li><a href="$(DOC)/packaging-manuals/java-policy/">Java Policy</a></li> - <li><a href="$(DOC)/packaging-manuals/perl-policy/">Perl Policy</a></li> - <li><a href="$(DOC)/packaging-manuals/python-policy/">Python Policy</a></li> - <li><a href="$(DOC)/packaging-manuals/debconf_specification.html">Debconf Specification</a></li> - <li><a href="https://www.debian.org/doc/manuals/dbapp-policy/">Database Application Policy</a> (draft)</li> - <li><a href="https://tcltk-team.pages.debian.net/policy-html/tcltk-policy.html/">Tcl/Tk Policy</a> (draft)</li> - <li><a href="https://people.debian.org/~lbrenta/debian-ada-policy.html">Debian Policy for Ada</a></li> - </ul> - - <p>Please take a look at <a - href="https://bugs.debian.org/debian-policy">proposed updates to - Debian Policy</a>, too.</p> - - <dl> - <dt><a href="$(DOC)/manuals/developers-reference/">Developers' Reference</a></dt> - - <dd> - Overview of the recommended procedures and the available resources - for Debian developers -- another <strong>must-read</strong>. - </dd> - - <dt><a href="$(DOC)/manuals/debmake-doc/">Guide for Debian Maintainers</a></dt> - - <dd> - How to build a Debian package (in common language), including - lots of examples. If you're planning to become a Debian developer - or maintainer, this is a good starting point. - </dd> - </dl> - - - </div> - - </div> - -</div> - - -<h2><a id="workinprogress">Work in Progress: Links for active Debian developers and maintainers</a></h2> - -<aside class="light"> - <span class="fas fa-wrench fa-5x"></span> -</aside> - -<dl> - <dt><a href="testing">Debian ‘Testing’</a></dt> - <dd> - Automatically generated from the ‘unstable’ distribution: - this is where you need to get your packages in order for them to be - considered for the next Debian release. - </dd> - - <dt><a href="https://bugs.debian.org/release-critical/">Release Critical Bugs</a></dt> - <dd> - A list of bugs which may cause a package to be removed from the - ‘testing’ distribution or may cause a delay for the - next release. Bug reports with a severity higher than or equal to - ‘serious’ qualify for the list, so please make sure to - fix those bugs against your packages as soon as you can. - </dd> - - <dt><a href="$(HOME)/Bugs/">Debian Bug Tracking System (BTS)</a></dt> - <dd> - For reporting, discussing, and fixing bugs. The BTS is useful - for both users and developers. - </dd> - - <dt>Information about Debian Packages</dt> - <dd> - The <a href="https://qa.debian.org/developer.php">package - information</a> and <a href="https://tracker.debian.org/">package - tracker</a> web pages provide collections of valuable - information to maintainers. Developers who want to keep - track of other packages, can subscribe (through email) - to a service which sends out copies of BTS mails and - notifications for uploads and installations. Please see the <a - href="$(DOC)/manuals/developers-reference/resources.html#pkg-tracker">package - tracker manual</a> for further information. - </dd> - - <dt><a href="wnpp/">Packages that need Help</a></dt> - <dd> - Work-Needing and Prospective Packages, WNPP for short, is a list - of Debian packages in need of new maintainers and packages that - have yet to be included in Debian. - </dd> - - <dt><a href="$(DOC)/manuals/developers-reference/resources.html#incoming-system">Incoming System</a></dt> - <dd> - Internal archive servers: this is where new packages are uploaded - to. Accepted packages are almost immediately available via a web - browser and propagated to <a href="$(HOME)/mirror/">mirrors</a> - four times a day. - <br /> - <strong>Note:</strong> Due to the nature of ‘incoming’, - we do not recommend mirroring it. - </dd> - - <dt><a href="https://lintian.debian.org/">Lintian Reports</a></dt> - <dd> - <a href="https://packages.debian.org/unstable/devel/lintian">Lintian</a> - is a program which checks whether a package conforms to the - policy. Developers should use it before every upload. - </dd> - - <dt><a href="$(DOC)/manuals/developers-reference/resources.html#experimental">Debian ‘Experimental’</a></dt> - <dd> - The ‘experimental’ distribution is used as a temporary - staging area for highly experimental software. Please install the - <a href="https://packages.debian.org/experimental/">experimental - packages</a> only if you already know how to use - ‘unstable’. - </dd> - - <dt><a href="https://wiki.debian.org/HelpDebian">Debian Wiki</a></dt> - <dd> - The Debian Wiki with advice for developers and other contributors. - </dd> -</dl> - -<h2><a id="projects">Projects: Internal Groups and Projects</a></h2> - -<aside class="light"> - <span class="fas fa-folder-open fa-5x"></span> -</aside> - -<ul> -<li><a href="website/">Debian Web Pages</a></li> -<li><a href="https://ftp-master.debian.org/">Debian Archive</a></li> -<li><a href="$(DOC)/ddp">Debian Documentation Project (DDP)</a></li> -<li><a href="https://qa.debian.org/">Debian Quality Assurance (QA) Team</a></li> -<li><a href="$(HOME)/CD/">CD/DVD Images</a></li> -<li><a href="https://wiki.debian.org/Keysigning">Keysigning</a></li> -<li><a href="https://wiki.debian.org/Keysigning/Coordination">Keysigning Coordination</a></li> -<li><a href="https://wiki.debian.org/DebianIPv6">Debian IPv6 Project</a></li> -<li><a href="buildd/">Autobuilder Network</a> and their <a href="https://buildd.debian.org/">Build Logs</a></li> -<li><a href="$(HOME)/international/l10n/ddtp">Debian Description Translation Project (DDTP)</a></li> -<li><a href="debian-installer/">The Debian Installer</a></li> -<li><a href="debian-live/">Debian Live</a></li> -<li><a href="$(HOME)/women/">Debian Women</a></li> -<li><a href="$(HOME)/blends/">Debian Pure Blends</a></li> - -</ul> - - -<h2><a id="miscellaneous">Miscellaneous Links</a></h2> - -<aside class="light"> - <span class="fas fa-bookmark fa-5x"></span> -</aside> - -<ul> -<li><a href="https://peertube.debian.social/home">Recordings</a> of our Conference Talks on PeerTube or using a - <a href="https://debconf-video-team.pages.debian.net/videoplayer/">different user interface</a></li> -<li><a href="passwordlessssh">Setting up SSH</a> so it doesn't ask you for a password</li> -<li>How to <a href="$(HOME)/MailingLists/HOWTO_start_list">request a new Mailing List</a></li> -<li>Information on <a href="$(HOME)/mirror/">Mirroring Debian</a></li> -<li>The <a href="https://qa.debian.org/data/bts/graphs/all.png">Graph of all Bugs</a></li> -<li><a href="https://ftp-master.debian.org/new.html">New Packages</a> waiting to be included in Debian (NEW Queue)</li> -<li><a href="https://packages.debian.org/unstable/main/newpkg">New Debian Packages</a> from the last 7 Days</li> -<li><a href="https://ftp-master.debian.org/removals.txt">Packages removed from Debian</a></li> -</ul> diff --git a/greek/devel/join/newmaint.wml b/greek/devel/join/newmaint.wml deleted file mode 100644 index c7e559c324b..00000000000 --- a/greek/devel/join/newmaint.wml +++ /dev/null @@ -1,156 +0,0 @@ -#use wml::debian::template title="Debian New Members Corner" BARETITLE="true" -#use wml::debian::translation-check translation="e75c4ef4f01457261f11a81e80de9862be35be30" maintainer="galaxico" - -<p>The Debian New Member process is the process of becoming an official -Debian Developer (DD). These webpages are the place where prospective Debian -Developers can find all the details on applying to become a DD, the -different steps of the process, and how to track the process of their ongoing -application.</p> - -<p>The first important point to make is that you do <em>not</em> need -to be an official Debian Developer in order to help improving -Debian. In fact, you should already have a track record of earlier -contributions to Debian before you apply for the New Member process.</p> - -<p><a name="non-maintainer-contributions"></a>Debian is an open community and -welcomes everyone who wants to use or help improve our distribution. As a -non-developer you can:</p> - -<ul> - <li>maintain packages through a <a href="#Sponsor">sponsor</a></li> - <li>create and/or review translations</li> - <li>create or improve documentation</li> - <li><a href="../website">help maintain the website</a></li> - <li>help with handling bugs (by providing patches, filing good bugs, - confirming the existence of the bug, finding ways to reproduce the - problem, ...)</li> - <li>be an active member of a packaging team (e.g. debian-qt-kde or debian-gnome)</li> - <li>be an active member of a subproject (e.g. debian-installer or debian-desktop)</li> - <li>etc</li> -</ul> - -<p>The <a href="$(DOC)/developers-reference/new-maintainer.html">Debian -Developer's Reference</a> contains several concrete suggestions on how -to do several of these tasks (in particular, how to find willing -sponsors).</p> - -<p>The Debian New Member process is the process of becoming an official -Debian Developer (DD). This is the traditional full membership role in -Debian. A DD can participate in Debian elections. Uploading DDs can upload -any package to the archive. Before applying as an uploading DD you should -have a track record of maintaining packages for at least six months. For -example uploading packages as a <a -href="https://wiki.debian.org/DebianMaintainer">Debian Maintainer -(DM)</a>, working inside a team or maintaining packages uploaded by -sponsors. Non-uploading DDs have the same permissions in the archive as -Debian Maintainers. Before -applying as non-uploading DD, you should have a visible and significant -track record of work inside the project.</p> - -<p>It is important to understand that the New Member process is part of -Debian's Quality Assurance efforts. It is hard to find developers who can spend -enough time on their Debian tasks, so we find it important to checking that -applicants are able to sustain their work, and do it well. Therefore we require -that prospective members have been actively involved in Debian for some time -already.</p> - -<p><a name="developer-priveleges"></a>Every Debian Developer:</p> -<ul> - <li>is member of the Debian project;</li> - <li>is allowed to vote about issues regarding the whole project;</li> - <li>can log in on most systems that keep Debian running;</li> - <li>has upload permissions for <em>all</em> packages - (except non-uploading Developers, who have the upload rights of a DM);</li> - <li>has access to the debian-private mailing list.</li> -</ul> - -<p>In other words, becoming a Debian Developer grants you several important -privileges regarding the project's infrastructure. Obviously this requires a -great deal of trust in and commitment by the applicant.</p> - -<p>Consequently the whole NM process is very strict and thorough. This is not -meant to discourage people interested in becoming a registered developer, but -it does explain why the New Member process takes so much time.</p> - -<p>Please read the <a href="#Glossary">glossary definitions</a> before -reading the rest of the pages.</p> - -<p>The following pages will be of interest to Applicants:</p> - -<ul> - <li><a href="nm-checklist">Checklist - required steps for Applicants</a> - <ul> - <li><a href="nm-step1">Step 1: Application</a></li> - <li><a href="nm-step2">Step 2: Identification</a></li> - <li><a href="nm-step3">Step 3: Philosophy and Procedures</a></li> - <li><a href="nm-step4">Step 4: Tasks and Skills</a></li> - <li><a href="nm-step5">Step 5: Recommendation</a></li> - <li><a href="nm-step6">Step 6: Front Desk Check</a></li> - <li><a href="nm-step7">Step 7: Debian Account Manager check and account creation</a></li> - </ul></li> - <li><a href="https://nm.debian.org/public/newnm">Entry Form</a></li> -</ul> - -<p>If you are a Debian Developer, and are interested in participating in the -New Member process, please visit these pages:</p> -<ul> - <li><a href="nm-amchecklist">Checklist for Application Managers</a></li> - <li><a href="nm-advocate">Advocating a prospective member</a></li> - <li><a href="nm-amhowto">Mini-HOWTO for Application Managers</a></li> - <li><a href="$(HOME)/events/keysigning">Mini-HOWTO for Keysigning</a></li> -</ul> - -<p>Miscellaneous:</p> -<ul> - <li><a href="https://nm.debian.org/">Status database for the New Member - process</a></li> - <li><a href="https://nm.debian.org/process/">List of current applicants</a></li> - <li><a href="https://nm.debian.org/public/managers">List of current application - managers</a></li> -</ul> - -<define-tag email><<a href="mailto:%0">%0</a>></define-tag> - -<h2><a name="Glossary">Glossary Definitions</a></h2> -<dl> - <dt><a name="Advocate">Advocate</a>:</dt> - <dd>A <a href="#Member">Debian Member</a> that advocates an application. They - should know the <a href="#Applicant">Applicant</a> fairly well and should be - able to give an overview of the Applicant's work, interests and plans. - Advocates are often the <a href="#Sponsor">Sponsors</a> of an Applicant. - </dd> - - <dt><a name="Applicant">Applicant</a>, New Member, historically also New Maintainer (NM):</dt> - <dd>A person requesting Debian membership as Debian Developer.</dd> - - <dt><a name="AppMan">Application Manager</a> (AM):</dt> - <dd>A <a href="#Member">Debian Member</a> who is assigned to an <a - href="#Applicant">Applicant</a> to collect the information needed by - the <a href="#DAM">Debian Account Managers</a> to decide about an - application. One Application Manager can be assigned to more than - one Applicant.</dd> - - <dt><a name="DAM">Debian Account Manager</a> (DAM): <email da-manager@debian.org></dt> - <dd>A <a href="#Member">Debian Member</a> that was delegated to manage - the Debian Account creation and removal by the Debian Project Leader (DPL). - The DAMs have the final decision over an application.</dd> - - <dt><a name="FrontDesk">Front Desk</a>: <email nm@debian.org></dt> - <dd>The Front Desk members do the infrastructural work for the NM process like - receiving the initial applications, advocation messages and final application - reports, and assigning AMs to NMs. They are the point of contact if problems - with the application arise.</dd> - - <dt><a name="Member">Member, Developer</a>:</dt> - <dd>A Debian member, who has gone - through the New Member process and had their application accepted.</dd> - - <dt><a name="Sponsor">Sponsor</a>:</dt> - <dd>A <a href="#Member">Debian Member</a> who acts as the mentor of - an Applicant: They check packages provided by the Applicant and help - to find problems and to improve the packaging. When the sponsor is - satisfied with the package, they upload it on behalf of the Applicant - to the Debian archive. The Applicant is recorded as the maintainer of - such a package, despite the fact Applicants do not upload - packages themselves.</dd> -</dl> diff --git a/greek/devel/join/nm-advocate.wml b/greek/devel/join/nm-advocate.wml deleted file mode 100644 index a3df5c2bba2..00000000000 --- a/greek/devel/join/nm-advocate.wml +++ /dev/null @@ -1,58 +0,0 @@ -#use wml::debian::template title="Advocating a prospective member" -#use wml::debian::translation-check translation="a0723d79bbfc5ed2266ada5ffd402b2d3ab47405" maintainer="galaxico" - -<p>Before advocating a prospective member, you should check that they -satisfy all things listed on the <a href="./nm-checklist">NM checklist</a>. -</p> - -<p>You should <em>only</em> advocate someone if you think that they are -ready to be a project member. This means that you should have known them for -some time and can judge their work. It is important that prospective -members have been working in the project for some time. Some ways -prospective members might be contributing include:</p> - -<ul> -<li>maintaining a package (or several),</li> -<li>helping users,</li> -<li>publicity work,</li> -<li>translations,</li> -<li>organizing work for debconf,</li> -<li>sending patches,</li> -<li>contributing bug reports,</li> -<li>... and much more!</li> -</ul> - -<p>These ways of helping are not mutually exclusive, of course! Many -prospective members will have done work in several areas of the -project, and not everyone must be a packager. Remember, <a -href="https://www.debian.org/vote/2010/vote_002">Debian welcomes -non-packaging contributors as project members</a>. For a wider -overview of a given contributor, you may be interested in <a -href="http://ddportfolio.debian.net/">tools which aggregate some -publicly-visible parts of the project</a>. Your personal knowledge of -the applicant is also important here. -</p> - -<p>The prospective member should be familiar with Debian's special -ways of doing things and should have already contributed actively and -effectively to the project. Most importantly, they should be -committed to the ideals and structure of the Debian project. Ask -yourself if you want to see them in Debian – if you think they -should be a Debian Developer then go ahead and encourage them to apply. -</p> - -<p>Next carry out the following steps: Agree with the prospective member -to recommend them and let them <a href="https://nm.debian.org/public/newnm">sign -up</a>. After that, you have to click on their name in the <a -href="https://nm.debian.org/process/">listing of Applicants</a> -and go the <q>Advocate this application</q> page. Enter your Debian login -and press the <q>Advocate</q> button. You then will receive an e-mail with an -auth key which you have to return PGP/GPG signed. After this, the -Applicant is added to the queue for an Application Manager with whom -they will go through all steps of the New Member checks. -</p> - -<p> -See also the <a href="https://wiki.debian.org/FrontDesk/AdvocacyTips">Advocacy Tips</a> -wiki page. -</p> diff --git a/greek/devel/join/nm-amchecklist.wml b/greek/devel/join/nm-amchecklist.wml deleted file mode 100644 index 9dd3ab6ae95..00000000000 --- a/greek/devel/join/nm-amchecklist.wml +++ /dev/null @@ -1,148 +0,0 @@ -#use wml::debian::template title="Checklist for Application Managers" -#use wml::debian::translation-check translation="5011f532637dc7820b79b151eecfda4ab65aa22f" maintainer="galaxico" - -<p> -<b>Note:</b> The <a href="https://wiki.debian.org/FrontDesk/AMTutorial">AM -Tutorial</a> wiki page is more up to date than this page. -</p> - -<p>This checklist only covers the most important areas of the NM checks. -Depending on the <a href="./newmaint#Applicant">Applicant's</a> -background and plans in the project, an <a href="./newmaint#AppMan">\ -Application Manager</a> may choose to ignore some of the things -listed here or to add others.</p> - -<p>Also see the <a href="nm-amhowto">Mini-HOWTO for Application -Managers</a>.</p> - -<h3><a name="identification">Identification Check</a></h3> -<p>The <a href="./newmaint#Applicant">Applicant</a> has to have - an OpenPGP public key signed by at least one <a href="./newmaint#Member">\ - Debian member</a>. If possible, at least one other signature - from a well-connected OpenPGP key is also required. Always - use <tt>gpg --check-sigs</tt>, not <tt>gpg --list-sigs</tt> to verify - an Applicant's identity.</p> - -<p>The OpenPGP key that will go to the Debian Keyring needs to be - a version 4 key. To check this, get the fingerprint of the key - and check if it's either 32 or 40 hexadecimal digits long. Version 3 - keys have only 32 digits, version 4 have 40 digits. This key - doesn't have to be the same as the one that is used to verify the - Applicant's identity.</p> - -<p>Applicants <em>must</em> have an encryption key. Check this by - running <tt>gpg --list-keys <var><KeyID></var></tt>. -If the output doesn't contain a line with either -<tt><var><Number></var>E/<var><KeyID></var></tt> or -<tt><var><Number></var>g/<var><KeyID></var></tt>, the -Applicant needs to add an encryption subkey.</p> - -<p>If the <a href="./newmaint#Applicant">Applicant</a> can't - provide a signed key, a government-issued photo ID can be used for - identification. Please contact the <a href="./newmaint#FrontDesk">\ - Front Desk</a> in such cases.</p> - -<p>Additional verification options can be used if there is some - doubt about the identity of the Applicant:</p> - -<ul> - <li>If the Applicant is a student, someone at their university can - confirm their identify. This person should also be listed on the - webpages of the university staff.</li> - - <li>If the Applicant works in a bigger company, their employer should - be able to confirm their identity.</li> - - <li>There are websites that can do reverse lookups for telephone - numbers, though this normally doesn't work for mobile phones. - The number the Applicant provides should either resolve to their - own name or the person answering the phone should be able to - confirm the Applicant's identity.</li> -</ul> - -<h3><a name="pandp">Philosophy and Procedures</a></h3> -<p>There are no fixed rules for this part, but some areas should - always be covered (and it is recommended to discuss the - others):</p> -<ul> - <li>Applicants have to agree to uphold the <a - href="$(DOC)/debian-policy/">Debian Policy</a> and the <a - href="$(DEVEL)/dmup">Debian Machine Usage Policy (DMUP)</a>.</li> - - <li>Applicants need to agree to the <a href="$(HOME)/social_contract">\ - Social Contract</a> and must be able to explain how Debian - relates to the Free Software Community.</li> - - <li>Applicants must have a good understanding of the <a - href="$(HOME)/social_contract#guidelines">Debian Free Software - Guidelines</a>. They need to be able to decide if a license is free - or not and should have a strong opinion about Free Software.</li> - - <li>Applicants have to understand how the Debian Bug Tracking - System works, what information Debian keeps in there (pseudo-packages, - wnpp, ...) and how they can manipulate it.</li> - - <li>Applicants should know about Debian QA processes (orphaning, - removing, NMUing and QA uploads).</li> - - <li>Applicants should understand the Debian release process.</li> - - <li>Applicants should know Debian's l10n and i18n efforts and what - they can do to help them.</li> -</ul> - -<h3><a name="tands">Tasks and Skills</a></h3> -<p>What needs to be covered by the T&S checks depends on the - area the Applicant wishes to work in:</p> - -<ul> - <li>Applicants aiming to work as packager <em>must</em> have at least - one package in the archive. The package should have enough users - to provide a basis for documentation of the Applicant's packaging - skills and their way of dealing with users, bug submitters and bugs. - <br /> - Further questions should also cover some basic aspects of Debian - packaging (conffiles, menus, init scripts, sub-policies, porting, - complex dependencies).</li> - - <li>Applicants planning to write documentation must have already - provided examples of their work. They should also have a clear vision - on what kind of documents they want to work on in the future.</li> -</ul> - -<h3><a name="finalreport">Final Application Report to the Debian -Account Manager</a></h3> -<p>After all checks are finished and the AM is satisfied with the - Applicant's performance, a report should be submitted to the Debian - Account Manager and the New Member Front Desk. It should - document what was done to satisfy the different parts of the New - Member checks and also contain all information collected - about the Applicant.</p> - -<p>The email should be directed at <da-manager@debian.org> and - <nm@debian.org> and contain the following - things:</p> - -<ul> - <li>A short overview about the application, containing some basic - information about the Applicant.</li> - - <li>The account name the Applicant requested. It should be at least - 3 characters long.</li> - - <li>The email address to which all mail directed at - <var><account></var>@debian.org should be forwarded.</li> - - <li>The fingerprint of the Applicant's OpenPGP public key that should be incorporated - into the Debian Keyring.</li> - - <li>An gzipped mbox with logs of all discussion between the Application Manager - and the Applicant about the application.</li> -</ul> - -<p>This completes the Application Manager's responsibilities in the - application process. The New Member Front Desk and the Account - Manager will check and judge the application report.</p> - -<hr /> -<a href="newmaint">Back to the New Members Corner</a> diff --git a/greek/devel/join/nm-amhowto.wml b/greek/devel/join/nm-amhowto.wml deleted file mode 100644 index fab5a29343f..00000000000 --- a/greek/devel/join/nm-amhowto.wml +++ /dev/null @@ -1,120 +0,0 @@ -#use wml::debian::template title="Mini-HOWTO for Debian New Members Application Managers" -#use wml::debian::translation-check translation="c3a3b8986d2ffef95ef7bb8f7d99f36678ff0e8f" maintainer="galaxico" - -<p> -<b>Note:</b> The <a href="https://wiki.debian.org/FrontDesk/AMTutorial">AM -Tutorial</a> wiki page is more up to date than this page. -</p> - -<h2>Documentation and Infrastructure for Application Managers</h2> - -<p>The basic information needed by Application Manager is provided -here, in the <a href="newmaint">New Members Corner</a>. Start -to look around until you're familiar with the process and all -requirements for Applicants.</p> - -<p>There are three important mail addresses for Application Managers:</p> - -<dl> - <dt>The New Member mailing list: <a href="https://lists.debian.org/debian-newmaint"> - debian-newmaint@lists.debian.org</a></dt> - <dd>This mailing list covers all aspects of the New Member process - and is used by the New Member group (Front Desk, Application - Managers, Debian Account Manager) and others to discuss - administrative issues and the New Member process. - If you have any questions regarding the NM process, you can ask - for help there. Please note that the list is archived publicly, so - questions of a highly personal nature shouldn't be discussed there. - Instead, you can ask the Front Desk privately.</dd> - - <dt>New Member Front Desk: nm@debian.org</dt> - <dd>This is where the initial applications, advocation messages and final - application reports get sent. Any personal questions about individual - applications which are inappropriate for a public forum should be - directed here as well.</dd> - - <dt>Debian Account Managers (DAMs): da-manager@debian.org</dt> - <dd>Normally, this address is only important to submit the final - application report. The DAMs are responsible for creating new accounts - on the Debian machines and adding New Members' OpenPGP keys to - the keyring. They also get to make the final decision on each - application, as the official New Member delegates of the Debian - Project Leader.</dd> -</dl> - -<p>The coordination of the NM process happens on <url -"https://nm.debian.org/"/>, where a website provides an interface to a -database containing all important information about NM applications. -Applicants can use the site to track their application status and -Application Managers can use it to organize their work.</p> - -<p>As Application Manager, you can log in over a secure https connection, -but please note that the password used on nm.debian.org is <em>not</em> the -one used for your normal Debian account (unless you change them to -match, but that's your business). You can record what you have done -with an Applicant and how many applicants you want to process at the -same time.</p> - -<p>To put someone on hold, you need to go to the applicant's status -page after you logged in and mark the "No" radio button for "AM approves -and submits report". You should also put a line into the AM comment field -to document why you did this.</p> - -<p>The rest of the pages is fairly self-explanatory. Some statistics -about all Application Managers are available, you can see an unsorted -list of all Applicants and change your AM profile.</p> - -<h2>Notes about the NM checks</h2> - -<p>As the NM-oriented documentation already provides enough information -about the requirements of the checks, nothing of that will be repeated -here. If you're unsure how to manage an applicant, use the excellent -templates provided by Joerg Jaspert's <a -href="https://salsa.debian.org/nm-team/nm-templates">nm-templates</a> -project. Questions should be asked on debian-newmaint@l.d.o or sent -to the Front Desk.</p> - -<h3>Putting an application on hold</h3> - -<p>Applicants that are either not able or not willing to invest enough -time into the New Member checks to finish them in a reasonable time -span (∼ 6 to 9 months) should be put on hold. That's not a problem or an -assessment of the Applicant's skills, but a simple reaction to the lack -of time. Many people want to join Debian, so Applicants shouldn't block -AM spots.</p> - -<p>You should discuss the possibility of setting an application on hold -when you get the feeling that it isn't moving forward, either because -the Applicant doesn't answer or because their only answer is "Yeah, will -do it soon". Emphasize the fact that getting off hold when they have -more time is no problem.</p> - -<h3>Other important notes</h3> - -<ul> - <li>Applicants should provide a short biography which can be sent to - debian-project@lists.debian.org in the regular "New Members" - email. That's very useful to introduce new members to the project. - Please note that the Applicant <em>has</em> to agree to the - publishing of this biography.</li> - - <li>Get some background information about the Applicant and put it - into the report — use your favourite search engine, private mail - archives, the BTS and all other means that come to your mind. - Sometimes the application process is too short to get a proper - impression of the Applicant's personality, so try to find out what - they did in the past.</li> - - <li>Ask sponsors and other people who worked closely together with - the Applicant to provide short statements about them. As more and - more packages are team-maintained, you can almost always find someone - who's able to tell you more about an Applicant. Include these - statements in the report.</li> - - <li>When checking the performance of a packaging Applicant, you should - be aware that one tiny package in the archive is not enough to - satisfy the Skills part of the T&S checks. The package should - have had more than one upload, some users (check popcon) and some - (closed, if possible) bug reports. This is important to see how an - Applicant interacts with users.</li> -</ul> diff --git a/greek/devel/join/nm-checklist.wml b/greek/devel/join/nm-checklist.wml deleted file mode 100644 index a5be6fe1149..00000000000 --- a/greek/devel/join/nm-checklist.wml +++ /dev/null @@ -1,105 +0,0 @@ -#use wml::debian::template title="Applicant's Checklist" -#include "$(ENGLISHDIR)/devel/join/nm-steps.inc" -#use wml::debian::translation-check translation="517d7a4f999561b8f28e207214a40990fdc3da49" maintainer="galaxico" - -<p>The information on this page, while public, will primarily -be of interest to future Debian Developers.</p> - -<h3>0. Contributing</h3> - -Before you decide to apply, you should already be contributing to Debian by -providing packages, translations, documentation, or any other activity. Usually -you are already registered as a <a -href="https://wiki.debian.org/DebianMaintainer">Debian Maintainer</a>, and have -been uploading your packages for six months. - -<p>The current registration process of New Members is divided -into 4 parts:</p> - -<h3>1. Application and Advocation</h3> -<p>Normally, the process is started with an application through the -<a href="https://nm.debian.org/public/newnm">New Member Application -web interface</a>. -<br> -After this step, the Applicant is known to the system and the Debian -New Member Front Desk is the primary contact for questions -concerning the Application. The Front Desk manages or supervises -all other steps and will try to help with all upcoming issues. -</p> - -<p>After the application is submitted to the system, an official Debian -Developer who has worked with the Applicant advocates them. This is -done with a signed email, containing a short text about the Applicant. -Normally, this mail covers topics like the background of the Applicant, -what they have done for Debian and a few bits about future plans.</p> - -<p>Then the Front Desk has a look to what the Applicant has already done -in the project. For the NM process to be the most efficient, Applicants -should have already contributed significantly to Debian. This can be done -through packaging, documentation, Quality Assurance, ...</p> - -<p><a href="./nm-step1">More ...</a></p> - -<h3>2. AM checks</h3> -<p>As soon as an Application Manager is available, the Front Desk -assigns one to the Applicant. The Application Manager's task is to -collect the information needed as a foundation for the decision -of the Debian Account Manager. This is divided into 4 parts:</p> - -<h4>ID check</h4> -<p>To maintain the strong Web of Trust that connects all Debian -Developers, Applicants need to identify themselves by providing an -OpenPGP key that is signed by at least two official Developers. To -further ensure their identity, signatures by other people (who do not -need to be DDs, but should be well connected in the overall Web of -Trust) are strongly recommended.</p> - -<p><a href="./nm-step2">More ...</a></p> - -<h4>Philosophy and Procedures checks</h4> -<p>As Debian is known for its strong ethical and philosophical -background, Applicants have to explain their own view about the -topic of Free Software. Debian has also evolved quite complicated -standard procedures to handle the problems of working in a large -group, so Applicants need to show that they know them and are -able to apply them to concrete situations.</p> - -<p><a href="./nm-step3">More ...</a></p> - -<h4>Tasks and Skills checks</h4> -<p>To ensure the overall quality of the Debian distribution, -Applicants need to show that they know their tasks in the area -they plan to work on (either documentation and internationalisation -or package maintenance). -#We have more areas, I'm sure of that - but I can't remember them now: FIXME -They also have to show their skills by submitting examples of their -work and answering some questions about it.</p> - -<p><a href="./nm-step4">More ...</a></p> - -<h4>Recommendation</h4> -<p>If the Application Manager is satisfied with the performance -of the Applicant, an Application Report is prepared and submitted -to the Front Desk and Debian Account Managers.</p> - -<p><a href="./nm-step5">More ...</a></p> - -<h3>3. Front Desk check</h3> -<p>The Application Report is checked by a member of the Debian Front Desk -for formal problems. If these are grave, the report is rejected and -the Application Manager has to correct the issue. If there are only minor -errors, these are reported to the Applicant and Application Manager.</p> - -<p><a href="./nm-step6">More ...</a></p> - -<h3>4. Debian Account Manager check and Account creation</h3> -<p>At this last stage of the process, the Application Report is judged. -If needed, further checks are either done by the Account Manager or -an Application Manager is asked to carry out a recheck. Sometimes -a Phone Call is required to finish the application.</p> - -<p>If all possible problems are resolved, the Debian Account Managers -assign an account to the Applicant and add their OpenPGP key to the -Debian keyring.</p> - -<p><a href="./nm-step7">More ...</a></p> diff --git a/greek/devel/join/nm-step1.wml b/greek/devel/join/nm-step1.wml deleted file mode 100644 index 4a9398de0fd..00000000000 --- a/greek/devel/join/nm-step1.wml +++ /dev/null @@ -1,89 +0,0 @@ -#use wml::debian::template title="Step 1: Application" NOHEADER="true" -#include "$(ENGLISHDIR)/devel/join/nm-steps.inc" -#use wml::debian::translation-check translation="0f3581ea8ff22d12b1665c2fb885ea6ccfe11f1c" maintainer="galaxico" - -<p>The information on this page, while public, will primarily -be of interest to future Debian Developers.</p> - -<h2>Step 1: Application</h2> - -<p>Before applying, prospective Developers should check that they are -prepared for all parts of the checks. To make this as easy as possible, -the most important prerequisites are listed below:</p> - -<ul> - <li><h4>The Applicant needs to agree with Debian's Philosophy</h4> - <p>It is needed that Applicants have read the - <a href="$(HOME)/social_contract">Social Contract</a> and the - <a href="$(HOME)/social_contract#guidelines">Debian Free Software - Guidelines</a> and agree to abide by them in their Debian-related work. - </p> - </li> - - <li><h4>The Applicant's identity needs to be verified</h4> - <p>This is done by having at least two signatures on the Applicant's - OpenPGP key from Debian Developers. It is also strongly recommended to have - more signatures from people who are well connected in the web of trust. - </p> - - <p>If the Applicant's location makes it <em>impossible</em> to get a key - signed by another Debian Developer, a scanned photo of their drivers license - or passport signed with their GPG key can be accepted as an alternative - method of identification. - </p> - </li> - - <li><h4>The Applicant needs to be able to perform their duties as a - developer</h4> - <p>This means that the Applicant should have experience of packaging and - package maintenance or experience of documenting or translating, depending - on the area they want to work in. - </p> - - <p>It's recommended that Applicants get a <a href="newmaint#Sponsor">sponsor</a> - to help them achieve this.</p> - </li> - - <li><h4>The Applicant needs to have read the developer documentation</h4> - <p>Later on in the process, the <a href="newmaint#AppMan">Application - Manager</a> will test the Applicant's knowledge of concepts described in - <a href="$(DOC)/debian-policy/">Debian Policy</a>, - <a href="$(DOC)/developers-reference/">Developers' Reference</a>, - <a href="$(DOC)/maint-guide/">New Maintainers' Guide</a> etc. - </p> - </li> - - <li><h4>The Applicant needs to have enough free time</h4> - <p>Finishing the New Member checks and being a Debian Developer - requires to invest time on a regular basis. Maintaining packages - in the main archive is a big commitment and can require quite - a lot of time.</p> - </li> - - <li><h4>The Applicant needs to have an <a href="newmaint#Advocate">\ - Advocate</a></h4> - <p>In order to persuade a developer to be your advocate, an Applicant should - get involved in Debian development – help tackle open bugs - against existing packages, adopt an orphaned package, work on the - installer, package useful new software, write or update documentation - etc. - </p> - </li> -</ul> - -<p>Once the Applicant has satisfied the above standards, they -can submit their <a href="https://nm.debian.org/public/newnm">New Member -Application</a>.</p> - -<p>After receiving the application, the <a href="./newmaint#FrontDesk"> -Front Desk</a> manages the application. As soon as someone is available -(this can take some weeks), it will assign them as the <a -href="./newmaint#AppMan">Application Manager</a> (AM) for the <a -href="./newmaint#Applicant">Applicant</a> (i.e. you).</p> - -<p>All further communication should happen between the Applicant and their -Application Manager, but if problems arise, the Front Desk is your primary -contact point.</p> - -<hr> -#include "$(ENGLISHDIR)/devel/join/nm-steps.inc" diff --git a/greek/devel/join/nm-step2.wml b/greek/devel/join/nm-step2.wml deleted file mode 100644 index 33e068f5343..00000000000 --- a/greek/devel/join/nm-step2.wml +++ /dev/null @@ -1,97 +0,0 @@ -#use wml::debian::template title="Step 2: Identification" NOHEADER="true" -#include "$(ENGLISHDIR)/devel/join/nm-steps.inc" -#use wml::debian::translation-check translation="b59849318da01faabdbc1d5bb5e05f99c4f7a61a" maintainer="galaxico" - -<p>The information on this page, while public, will primarily -be of interest to future Debian developers.</p> - - -<h2>Step 2: Identification</h2> - -<h3>Why OpenPGP?</h3> - -<p>Debian makes extensive use of OpenPGP because <a -href="newmaint#Member">Debian members</a> are located all over the world -(see the <a href="$(DEVEL)/developers.loc">developer locations</a>) and rarely -meet each other in person. This means trust cannot be built up by -personal contact and other means are necessary. All Debian developers -are identified by their <a href="http://www.gnupg.org/">OpenPGP</a> -key. These keys make it possible to authenticate messages and -other data by signing it. For more information on OpenPGP keys -see the README file in the <code>debian-keyring</code> package.</p> - -<h3>Providing a key</h3> - -<p>Each <a href="newmaint#Applicant">Applicant</a> must provide an -OpenPGP version 4 public key with encryption capabilities. The -preferred way to do this is to export it to one of the public key -servers, such as <tt>subkeys.pgp.net</tt>. -Public keys can be exported using:</p> -<pre> -gpg --send-key --keyserver <server address> <yourkeyid> -</pre> - -<p>If your key has no encryption capability, you can simply add -an encryption subkey.</p> - -<p>See <a href="https://keyring.debian.org/">keyring.debian.org</a> -for more information on key formats and properties.</p> - - -<h3>Verification</h3> - -<p>Since anyone can upload a public key to the servers it needs -to be verified that the key belongs to the Applicant.</p> - -<p>To accomplish this the public key itself must be signed by two other -<a href="newmaint#Member">Debian members</a>. Therefore the -Applicant must meet this Debian member in person and must -identify himself (by providing a passport, a driver's license -or some other ID).</p> - - -<h4><a name="key_signature">How to get your OpenPGP key signed</a></h4> - -<p>There are several ways to find a Debian member for a key -exchange. You should try them in the order listed below:</p> - -<ol> - -<li>Announcements of key signing parties are usually posted on the -<code>debian-devel</code> mailing list, so check there first.</li> - -<li><p>You can look for developers in specific areas through the <a -href="https://wiki.debian.org/Keysigning">key signing coordination page</a>:</p> - -<ul> - <li>First you should check the list of key signing offers for a Debian - member near you.</li> - <li>If you cannot find a Debian member among the key signing offers, - you can register your key signing request.</li> -</ul> -</li> - -<li>If no one has reacted to your request for several weeks, send an -e-mail to <email debian-private@lists.debian.org> telling them exactly -where you live (plus naming some big cities close to you), -then they can check in the developer database for developers who are -near you.</li> - -</ol> - -<p>Once you find someone to sign your key, you should follow the steps -in the <a href="$(HOME)/events/keysigning">Keysigning Mini-HOWTO</a>.</p> - -<p>It is recommended that you also sign the Debian Developer's -key. This is not necessary for your ID check but it strengthens the -web of trust.</p> - - -<h4>When you can't get your key signed</h4> - -<p>If all of the steps above fail, please contact the -<a href="newmaint#FrontDesk">Front Desk</a> and ask for help. They may -offer you an alternate way of identification.</p> - -<hr> -#include "$(ENGLISHDIR)/devel/join/nm-steps.inc" diff --git a/greek/devel/join/nm-step3.wml b/greek/devel/join/nm-step3.wml deleted file mode 100644 index 71e913cc044..00000000000 --- a/greek/devel/join/nm-step3.wml +++ /dev/null @@ -1,167 +0,0 @@ -#use wml::debian::template title="Step 3: Philosophy and Procedures" NOHEADER="true" -#include "$(ENGLISHDIR)/devel/join/nm-steps.inc" -#use wml::debian::translation-check translation="517d7a4f999561b8f28e207214a40990fdc3da49" maintainer="galaxico" - -<p>The information on this page, while public, will primarily -be of interest to future Debian Developers.</p> - -<h2>Step 3: Philosophy and Procedures</h2> - -<h3>Philosophy</h3> -<p> -The <a href="./newmaint#Applicant">Applicant</a> is expected to fit -into the Debian community, which is built around the philosophy of -Free Software. What Debian understands as "free" and how this is -applied is explained in the <a href="$(HOME)/social_contract">Social -Contract</a> and the <a href="$(HOME)/social_contract#guidelines">Debian -Free Software Guidelines</a>. -<br /> -Prospective Developers need to understand these documents well enough to -express the ideas and ideals described there in their own words. Just -exactly how this understanding is accomplished and communicated is left -up to the Applicant and their manager to determine. The following methods -are only intended as a suggestion, not as a requirement, but they are -examples of ways to complete this step of the process. Several -opportunities will be provided for the Applicant to show understanding in -these areas. -</p> - -<p>Note: Though we require Applicants to agree with the Debian philosophy, -this is limited to work done for Debian. We understand that people need -to earn their living and are sometimes required to work on non-free -projects for their employer or customer.</p> - -<p>Debian makes no attempt to control what the Applicant thinks about these -subjects, but it is important to the stability of such a large and amorphous -project that all participants work within the same set of basic principles -and beliefs.</p> - -<p>The <a href="./newmaint#AppMan">Application Manager</a> (AM) will -decide when the criteria for each step have been satisfied. The following -guidelines only try to provide useful examples. In most cases, a mix -of all of them will be used. -<br> -The AM and the <a href="./newmaint#Applicant">Applicant</a> may decide -on other tasks than the ones specified here. Those tasks must be -documented clearly in the final report to the <a href="./newmaint#DAM">\ -Debian Account Manager</a>.</p> - -<dl> - <dt>1. The <a href="$(HOME)/social_contract">Social Contract</a></dt> - <dd><p> - The Social Contract declares Debian's goals and aspirations. It - also tries to express our self-imposed responsibilities to the rest - of the community. - <br /> - A proper understanding of the priorities we give to these various - responsibilities and agreement with them is essential for any - Applicant. - </p> - - <p>The understanding can be documented in various ways:</p> - - <ul> - <li>A discussion with the AM about the various terms in the Social - Contract, expressing how they relate to each other and Debian's - organization.</li> - - <li>A discussion about the Applicant's personal goals for Debian, - how they fit in with the Social Contract can in some cases - be enough.</li> - - <li>The Applicant can put the Social Contract in their own words, - explaining some of the more complex parts and how Debian - strives to comply to them.<br /> - Note: This is the usually chosen way. - </li> - </ul> - <br> - </dd> - - <dt>2. The <a href="$(HOME)/social_contract#guidelines">Debian Free - Software Guidelines</a></dt> - <dd> - <p>These principles act as guidelines for determining the freedom - delivered by a particular license.</p> - - <p>Although most Applicants aren't lawyers, every one should be - able to express and use the understanding of the basic principles - set forth in these guidelines.</p> - - <p>The understanding can be documented in various ways:</p> - - <ul> - <li>The Applicant discusses several licenses and tries to show - if they're free or not. In this process, the AM can point out - special cases and ask further questions regarding the DFSG.<br> - Note: This is the usually chosen way. - </li> - - <li>The Applicant compares the Debian Free Software Guidelines -#FIXME: "statements" is so wrong, but I already used guidelines... - to other statements about Free Software and points out - similarities and differences. - </li> - </ul> - </dd> -</dl> - -<p>Whatever method is used, the Applicant must agree with these -principles, as well as show an understanding of their meaning and -content.</p> - -<p> -Failure to agree with these terms will terminate the application process. -</p> - -<h3>Procedures</h3> - -<p>The standard procedures and policies that have evolved in the creation -of the Debian system are very important to manage the distributed work -of volunteers. They ensure the overall quality of Debian and often help -to prevent problems between Developers by providing a set of guidelines -for the interaction in special cases.</p> - -<p>How the <a href="./newmaint#Applicant">Applicant</a> has to show -their understanding is up to the <a href="./newmaint#AppMan">Application -Manager</a>, but there are some essentials that should always be covered. -The following list documents what is a must for the Procedures checks:</p> - -<ul> - <li><h4>Working with the Bug Tracking System</h4> - Debian uses the <a href="https://bugs.debian.org/">Bug Tracking System</a> - (BTS) not only to keep track of bugs in packages, but also to gather - requests about the infrastructure and manage the work-needing and - prospective packages. - <br /> - Prospective Developers need to be able to control the BTS and explain - how it can be used to represent all available data about problems. - </li> - - <li><h4>The Debian release process</h4> - Debian's release process is the base for its stability and security, - so prospective Developers need to understand how it works, why it - is structured as it is and what exceptions are possible. - </li> - - <li><h4>Debian's internationalisation and localisation efforts</h4> - Considering that only a small part of the world speaks English - natively, Developers and Translators invest a significant amount - of time to make Debian useable for everybody. There are a lot of - specific tools and rules and prospective Developers should be aware - of them. - </li> -</ul> - -<p>There are of course many other topics that can be covered by -the New Member checks, but the AM should only choose those -that are relevant for the area the Applicants wants to work in. -The most important quality is that prospective Developers know -where to look for information concerning them.</p> - -<p><a href="./newmaint#Applicant">Applicants</a> should also read -<a href="$(DEVEL)/dmup">the Debian Machine Usage Policy (DMUP)</a> -and agree to abide by it.</p> - -<hr /> -#include "$(ENGLISHDIR)/devel/join/nm-steps.inc" diff --git a/greek/devel/join/nm-step4.wml b/greek/devel/join/nm-step4.wml deleted file mode 100644 index 81b412eb537..00000000000 --- a/greek/devel/join/nm-step4.wml +++ /dev/null @@ -1,56 +0,0 @@ -#use wml::debian::template title="Step 4: Tasks and Skills" NOHEADER="true" -#include "$(ENGLISHDIR)/devel/join/nm-steps.inc" -#use wml::debian::translation-check translation="517d7a4f999561b8f28e207214a40990fdc3da49" maintainer="galaxico" - -<p>The information on this page, while public, will primarily be of -interest to future Debian Developers.</p> - -<h2>Step 4: Tasks and Skills</h2> - -<p>Most of the current members of the <a href="./newmaint#DebianProject"> -Debian Project</a> maintain one or more packages for the distribution. -However there are many other jobs that need to be done that do not -involve package management.</p> - -<p>The <a href="./newmaint#AppMan">Application Manager</a> will -work out with the <a href="./newmaint#Applicant">Applicant</a> -which tasks the Applicant volunteers to perform. After that, the -Applicant will need to demonstrate their skills in this area.</p> - -<p>The following tasks are obvious examples of the various jobs available -to the Applicant, but they don't necessarily include everything an -Applicant may find interesting and productive for the group. Additional -tasks may be defined by the AM and the Applicant.</p> - -<p>Some example tasks are:</p> - -<ul> - <li><h4>Package Management</h4> - By maintaining a package, a prospective Developer can show their - understanding of the <a href="$(DOC)/debian-policy/">Debian Policy</a> - and how they work with Debian users and bug submitters. - </li> - - <li><h4>Documentation</h4> - The Applicant can demonstrate their skills in this area by writing - man pages for executables that don't have one, by updating an outdated - document and by creating new documentation that is required by - users, but still missing from the distribution. - </li> - - <li><h4>Debugging, Testing and Patching</h4> - The Applicant can show skills in this area either by working on - fixing bugs with the QA team, or by testing installation process or - individual packages working with the testing team. The Applicant - can fix bugs in existing Debian packages or file bug reports in - the Debian BTS describing problems and enclosing patches. - </li> -</ul> - -<p>Alternative demonstration tasks can be worked out between the -Applicant and the Application Manager. Such alternative tasks need to -be coordinated with the <a href="./newmaint#FrontDesk">Front Desk</a> -and the <a href="./newmaint#DAM">Debian Account Manager</a>.</p> - -<hr> -#include "$(ENGLISHDIR)/devel/join/nm-steps.inc" diff --git a/greek/devel/join/nm-step5.wml b/greek/devel/join/nm-step5.wml deleted file mode 100644 index fcb0912a163..00000000000 --- a/greek/devel/join/nm-step5.wml +++ /dev/null @@ -1,30 +0,0 @@ -#use wml::debian::template title="Step 5: Recommendation" NOHEADER="true" -#include "$(ENGLISHDIR)/devel/join/nm-steps.inc" -#use wml::debian::translation-check translation="7606615ccc824d084b77b8389bc4b0de77974b15" maintainer="galaxico" - -<p>The information on this page, while public, will primarily be of -interest to future Debian Developers.</p> - -<h2>Step 5: Recommendation</h2> - -<p>When the <a href="./newmaint#Applicant">Applicant</a> has completed -the tasks and skills tests, expressed an understanding of the <a -href="$(HOME)/social_contract">Social Contract</a>, the -<a href="$(HOME)/social_contract#guidelines">Debian Free Software -Guidelines</a> and Debian Policies and Procedures and been properly -identified, it is time for the <a href="./newmaint#AppMan">Application -Manager</a> to make <a href="./nm-amchecklist#finalreport">a final -report</a> to the <a href="./newmaint#FrontDesk">Front Desk</a> and -the <a href="./newmaint#DAM">Debian Account Manager</a>.</p> - -<p>This report includes statements from the <a href="./newmaint#Advocate"> -Advocate</a> and other people who have worked with the Applicant, -the completed identification information, all discussions between the -Application Manager and the Applicant and details about the Skill checks, -as well a comment from the Application Manager.</p> - -<p>The <a href="./newmaint#AppMan">Application Manager</a> will include a -recommendation to either accept or reject the Applicant.</p> - -<hr> -#include "$(ENGLISHDIR)/devel/join/nm-steps.inc" diff --git a/greek/devel/join/nm-step6.wml b/greek/devel/join/nm-step6.wml deleted file mode 100644 index 29def819121..00000000000 --- a/greek/devel/join/nm-step6.wml +++ /dev/null @@ -1,24 +0,0 @@ -#use wml::debian::template title="Step 6: Front Desk Check" NOHEADER="true" -#include "$(ENGLISHDIR)/devel/join/nm-steps.inc" -#use wml::debian::translation-check translation="7606615ccc824d084b77b8389bc4b0de77974b15" maintainer="galaxico" - -<p>The information on this page, while public, will primarily be of -interest to future Debian Developers.</p> - -<h2>Step 6: Front Desk Check</h2> - -<p>After the <a href="./newmaint#AppMan">Application Manager</a> has -prepared the final report about the <a href="./newmaint#Applicant"> -Applicant</a>, the <a href="./newmaint#FrontDesk">Front Desk</a> -checks the report. If it covers all needed areas and documents all -parts of the NM checks, it is approved. Little problems and errors -are pointed out to the <a href="./newmaint#AppMan">Application -Manager</a> and <a href="./newmaint#Applicant">Applicant</a>.</p> - -<p>If the report is incomplete, the <a href="./newmaint#FrontDesk">Front -Desk</a> either decides to send it back to <a href="./newmaint#AppMan"> -Application Manager</a> to complete it or asks another <a -href="./newmaint#AppMan">Application Manager</a> to finish it.</p> - -<hr> -#include "$(ENGLISHDIR)/devel/join/nm-steps.inc" diff --git a/greek/devel/join/nm-step7.wml b/greek/devel/join/nm-step7.wml deleted file mode 100644 index 52e303b8945..00000000000 --- a/greek/devel/join/nm-step7.wml +++ /dev/null @@ -1,35 +0,0 @@ -#use wml::debian::template title="Step 7: Debian Account Manager check and account creation" NOHEADER="true" -#include "$(ENGLISHDIR)/devel/join/nm-steps.inc" -#use wml::debian::translation-check translation="7606615ccc824d084b77b8389bc4b0de77974b15" maintainer="galaxico" - -<p>The information on this page, while public, will primarily be of -interest to future Debian Developers.</p> - -<h2>Step 7: Debian Account Manager check and account creation</h2> - -<p>The <a href="./newmaint#DAM">Debian Account Manager</a> has to make -the final decision about the account creation. If any major problems -in the application are found, it is either directly rejected or given -back to the <a href="./newmaint#FrontDesk">Front Desk</a>, which decides -how to complete the application.</p> - -<p>There are some problems that always lead to a rejection:</p> -<ul> - <li>Failure to provide adequate identification.</li> - <li>Failure to agree to our principles and procedures.</li> - <li>Failure to complete the tasks the Applicant agreed to do with - their Application Manager.</li> -</ul> - -<p>When the <a href="./newmaint#DAM">Debian Account Managers</a> are -satisfied with the complete application, they ask the Debian Keyring maintainers -to add the Applicant's key, and the Debian System Administrators to create the -necessary accounts for the Applicant and subscribe the Applicant to -the debian-private mailing list.</p> - -<p>Once all the final details of membership have been completed by the -<a href="./newmaint#DAM">Debian Account Managers</a>, the Applicant, -their AM and the debian-project mailing list will be informed.</p> - -<hr> -#include "$(ENGLISHDIR)/devel/join/nm-steps.inc" diff --git a/greek/devel/leader.wml b/greek/devel/leader.wml deleted file mode 100644 index 46c68bf7b10..00000000000 --- a/greek/devel/leader.wml +++ /dev/null @@ -1,74 +0,0 @@ -#use wml::debian::template title="Debian Project Leader" BARETITLE="true" -#use wml::debian::translation-check translation="9f2c3e2f64ffd99731f45de697c0b4c733e68ced" maintainer="galaxico" - -#include "$(ENGLISHDIR)/devel/leader.data" - -<p>The Debian Project Leader (DPL) is the official -representative of the Debian Project. They have two main functions, -one internal and one external.</p> - -<p>In the external function, the Project Leader represents the Debian -Project to others. This involves giving talks and presentations about -Debian and attending trade shows, as well as building good relationships -with other organizations and companies.</p> - -<p>Internally, the Project Leader manages the project and defines its -vision. They should talk to other Debian developers, especially to the -delegates, to see how they can assist their work. A main task of the -Project Leader therefore involves coordination and communication.</p> - - -<h2>Appointment</h2> - -<p>The Project Leader is chosen in an election in which all Debian -Developers are eligible to vote. The Project Leader's term of office is -one year. Six weeks before the leadership post becomes vacant, the -<a href="secretary">Project Secretary</a> initiates a new election. During -the first week, any Debian Developer can become a candidate for this -post by nominating themselves. The next three weeks are used for -campaigning. Each candidate posts their platforms and everyone can direct -questions to one or all candidates. The last two weeks consist of the -polling period during which developers may cast their votes.</p> - -<p>More information about the leader elections are available at -<a href="../vote/">the voting pages</a>.</p> - - -<h2>Tasks performed by the Project Leader</h2> - -<h3>Appoint Delegates or delegate decisions to the - <a href="tech-ctte">Technical Committee</a></h3> - -<p>The Project Leader may define a specific area of responsibility and -delegate it to a Debian developer.</p> - -<h3>Lend authority to other Developers</h3> - -<p>The Project Leader may make statements of support for points of -view or for other members of the project.</p> - -<h3>Make any decision which requires urgent action</h3> - -<h3>Make any decision for whom nobody else has responsibility</h3> - -<h3>In consultation with the developers, make decisions affecting property held -in trust for purposes related to Debian</h3> - -<p>The Project Leader may make decisions about how money owned by Debian is -to be used.</p> - - -<h2>Contact information</h2> - -<p>Contact the Debian Project Leader by sending e-mail in English -to <email "leader@debian.org">.</p> - -<h1>About Our Current Leader</h1> - -<p>The current Debian Project Leader is <current_leader>.</p> - -<h2>Past leaders</h2> - -<p>A complete list of past leaders can be found in the -<a href="$(DOC)/manuals/project-history/leaders">Debian Project -History</a>.</p> diff --git a/greek/devel/passwordlessssh.wml b/greek/devel/passwordlessssh.wml deleted file mode 100644 index 4b7b77841d4..00000000000 --- a/greek/devel/passwordlessssh.wml +++ /dev/null @@ -1,53 +0,0 @@ -#use wml::debian::template title="How to set up ssh so you aren't asked for a password" BARETITLE=true -#use wml::debian::translation-check translation="87a9a20b860797210702af5b17db09a362a220e7" maintainer="galaxico" - -<p>You can create a RSA authentication key to be able to log into a remote -site from your account, without having to type your password.</p> - -<p>Note that once you've set this up, if an intruder breaks into your -account/site, they are given access to the site you are allowed in without a -password, too! For this reason, this should <strong>never</strong> be -done from root.</p> - -<ul> - <li>Run <code>ssh-keygen(1)</code> on your machine, and just hit - enter when asked for a password. - <br> - This will generate both a private and a public key. With older - SSH versions, they will be stored in - <code>~/.ssh/identity</code> and - <code>~/.ssh/identity.pub</code>; with newer ones, they - will be stored in <code>~/.ssh/id_rsa</code> and - <code>~/.ssh/id_rsa.pub</code>.</li> - <li>Next, add the contents of the public key file into - <code>~/.ssh/authorized_keys</code> on the remote site (the file - should be mode 600). - <br> - If you are a developer and you want to access debian.org systems with - such a key, it's possible to have the developer database propagate - your key to all of the debian.org machines. See the - <a href="https://db.debian.org/doc-mail.html">LDAP gateway - documentation</a>.</li> -</ul> - -<p>You should then be able to use ssh to log in to the remote server -without being asked for a password.</p> - -<p><strong>Important:</strong> Note that everyone that has read access -to the private key file can use it to have the same passwordless -access to the remote site. This includes any person that has root -access to your local machine. Therefore it's strongly recommended -that you use a passphrase for your private key if you are not the only -root on your machine. You can use <code>ssh-agent(1)</code> and -<code>ssh-add(1)</code> to type your passphrase only once for all uses -of a specific key in a session. You can automatically load all your -keys in the agent by adding the following lines to your -<code>~/.xsession</code> file:</p> -<pre> - \# if use-ssh-agent is specified in /etc/X11/Xsession.options - \# (this is the default) then you need only the second line - \# eval ssh-agent - ssh-add <filename-of-ssh-key> -</pre> -<p>The <code>ssh-askpass</code> package must be installed in order to -run <code>ssh-add</code> without a terminal.</p> diff --git a/greek/devel/secretary.wml b/greek/devel/secretary.wml deleted file mode 100644 index 1f9a1ec35fc..00000000000 --- a/greek/devel/secretary.wml +++ /dev/null @@ -1,127 +0,0 @@ -#use wml::debian::template title="Debian Project Secretary" BARETITLE="true" NOHEADER="true" -#use wml::debian::translation-check translation="965001d7d8f032b9d41bfa609f0cca3bc3c927d3" maintainer="galaxico" - - <h1 class="title">The Debian Project Secretary</h1> - - <p class="initial"> - As the <a href="$(HOME)/">Debian project</a> grew, - it became apparent that there needed to be a set of semi-formal - rules to help in conflict resolution, and as a result the - constitution was written. The Debian - <a href="constitution">constitution</a> - describes the organisational structure for formal decision - making in the Project. The constitution delineates who makes - decisions, and what powers are attached to each such decision - making individual or body. The office of the Project Secretary - is one of the six entities enumerated in the Debian constitution - as a decision making entity. - </p> - - <p> - Any Debian developer is eligible to be considered for the post - of the Debian Project Secretary. Any person may hold several - posts, except that the Project Secretary may not also be the - <a href="leader">Debian Project Leader</a>, or the Chair of the - <a href="tech-ctte">Technical Committee</a>. - </p> - - <h2>Appointment</h2> - - <p> - Unlike other delegates, who are appointed by the - <a href="leader">Project Leader</a>, - the next Project Secretary is appointed by the Project Leader - and the current Project Secretary. In case the current secretary - and the project leader disagree, they must ask the Developers by - way of general resolution to appoint a Secretary. - </p> - - <p> - The Project Secretary's term of office is 1 year, at which point - they or another Secretary must be (re)appointed. - </p> - - <h2>Tasks performed by the Project Secretary</h2> - - - <h3>Conducting votes</h3> - <p> - The most visible task performed by the secretary is conducting - <a href="$(HOME)/vote/">votes</a> for the project - -- notably the Project Leader elections, but also any other - votes that are run (General Resolutions, for example). Running a - vote also entails determining the number and identity of the - people eligible to vote, for the purpose of calculating quorum. - </p> - - <h3>Standing in for other Officers</h3> - - <p> - The Project Secretary can stand in for the Leader, together with - the Chair of the Technical Committee. In this situation, they - may jointly make decisions if they consider it imperative to do - so -- but only when absolutely necessary and only when - consistent with the consensus of the Developers. - </p> - - <p> - 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 Chair of the - Technical Committee, as Acting Secretary. - </p> - - <h3>Interpreting the Constitution</h3> - - <p> - The secretary is also responsible for adjudicating any disputes - about interpretation of the constitution. - </p> - - - <h2>Contact information</h2> - - <p>Contact the Debian Project Secretary by sending e-mail in English to - <email "secretary@debian.org">.</p> - - - <h1 class="center">About Our Current Secretary</h1> - - <p> - The current Project Secretary is Kurt Roeckx - <<email "kroeckx@debian.org">>. - Kurt has been involved with free software and linux since 1995, and has - been a Debian Developer since - <a href='https://lists.debian.org/debian-project/2005/08/msg00283.html'>August 2005</a>.<br /> - Kurt has a Masters degree in Electronics and ICT, awarded by Hogeschool - voor Wetenschap & Kunst. - </p> - - <p> - Kurt has been Project Secretary since February 2009; he took up the - position after the previous secretary, Manoj Srivastava, resigned from - the position. Apart from being Project Secretary, Kurt is an AMD64 porter - and maintains - <a href="https://qa.debian.org/developer.php?login=kurt@roeckx.be">12 packages</a> - including libtool, ntp and openssl. - </p> - - <h2>The assistant secretary post</h2> - - <p> - Due to the increasing amount of work (i.e.: votes) that the secretary was - starting to need to handle, the DPL (at the time, Steve McIntyre) and the - previous secretary (Manoj) decided that it would be a good idea to - appoint an assistant in cases of unavailability.<br /> - Currently, Neil McGovern <<email "neilm@debian.org">> serves in - this position. - </p> - - <hrline> - <address> - <a href="mailto:secretary@debian.org">The Debian Project Secretary</a> - </address> - -## Local variables: -## sgml-default-doctype-name: "HTML" -## End: diff --git a/greek/devel/tech-ctte.wml b/greek/devel/tech-ctte.wml deleted file mode 100644 index 73883c2fb80..00000000000 --- a/greek/devel/tech-ctte.wml +++ /dev/null @@ -1,370 +0,0 @@ -#use wml::debian::template title="Debian Technical Committee" BARETITLE="true" -#use wml::debian::toc -#use wml::debian::translation-check translation="c64de4f08b1bd899f017c8059cc6622fd4cd5910" maintainer="galaxico" - -<p>The Technical Committee is established by the -<a href="constitution">Debian Constitution</a>, section 6. It is the body -which makes the final decision on technical disputes in the Debian project. -</p> - -<toc-display/> - -<toc-add-entry name="referquestions">How to refer a question to the committee</toc-add-entry> - -<ol> - -<li>Before referring a decision to the Technical Committee, you should try - to resolve it yourself. Engage in a constructive discussion and try - to understand the other person's point of view. If, after discussion, - you've identified a technical question which you can't agree on, you - can put it to the committee: -</li> - -<li>Write up a summary of the disagreement, preferably agreeing it with - your opponent, and send it to the bug tracking system - <em>as a new bug</em>, against the pseudo-package <tt>tech-ctte</tt>. - In your summary mention any relevant existing bug numbers and mailing - list archive urls. -</li> - -<li>Send an email to all relevant parties inviting them to subscribe to the - bug. If there are existing bug(s) open about the - issue, set the new tech-ctte bug to block them (but if you don't know - how to do this, don't worry - we will do it for you.) - -<li>The committee will discuss your question in the tech-ctte bug. - We will generally not CC discussion to individual participants, - unless we invite them into the conversation to ask them a specific - question. Everyone who is interested in the issue should subscribe - to the bug using the BTS. - -<li>The committee will aim to make a decision as soon as possible. In - practice this process is likely to take many weeks, or perhaps - longer. If the question is particularly urgent please say so. -</li> - -<li>Sometimes, one side or other is convinced, during the committee's - deliberations, by the merit of the other side's arguments. This is a - good thing! If it happens, the committee need not make a formal - decision, and the bug report can be closed, or reassigned, as appropriate. -</li> - -</ol> - -<h3>Some caveats about contacting the committee</h3> - -<ul> - -<li>A sound and vigorous debate is important to ensure that all the - aspects of an issue are fully explored. When discussing technical - questions with other developers you should be ready to be challenged. - You should also be prepared to be convinced! There is no shame in - seeing the merit of good arguments. -</li> - -<li>Please conduct your technical discussions with other maintainers - in a calm and civilised way; do not use insults, or question their - competence. Instead, address yourself to your opponents' arguments. -</li> - -<li>The committee is only empowered to make technical decisions. If - you feel that someone has been misbehaving, the committee probably - can't help you much. You may wish to talk to the Project Leader, - <tt>leader@debian.org</tt>. -</li> - -<li>The bug traffic will also appear on the committee mailing list, - <a href="https://lists.debian.org/debian-ctte/">debian-ctte@lists.debian.org</a>. Anyone else who wishes to do so may subscribe to - the debian-ctte mailing list and see our deliberations. But please - do not send messages relating to specific issues directly to the - list. -</li> - -<li>To post to the committee mailing list you must either be - subscribed to the list from your posting address, or PGP-sign your - message. This is an anti-spam measure. We apologise for the - inconvenience, but this setup makes it possible for committee - members to pay proper attention to the committee list mails. -</li> - -</ul> - -<toc-add-entry name="membership">Membership</toc-add-entry> - -<p>The current membership of the committee is documented on the -<a href="$(HOME)/intro/organization#tech-ctte">\ -Debian Organizational Structure</a> page. -</p> - -<toc-add-entry name="status">Archives and status</toc-add-entry> - -<p>The <a href="https://lists.debian.org/debian-ctte/">committee mailing list -is archived</a>.</p> - -<p><a href="https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=tech-ctte">Questions pending decision</a> -can be reviewed in the bug tracking system.</p> - -<toc-add-entry name="repository">VCS repository</toc-add-entry> - -<p>The TC sometimes uses its -<a href="https://salsa.debian.org/debian/tech-ctte">\ -shared git repository</a> -for collaboration.</p> - -<h3>Formal technical decisions, including recommendations and advice</h3> - -<p> The decision history sections are not necessarily up to date. - (<a href="https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=tech-ctte;archive=yes">Older - questions and decisions</a> can be viewed in the bug tracking - system.)</p> - -<ul> - <li><a href="https://lists.debian.org/debian-devel-announce/2019/03/msg00001.html">2019-03-05</a> - <a href="https://bugs.debian.org/914897">Bug #914897:</a>The - technical committee decided to decline to override the <a - href="https://wiki.debian.org/Debootstrap">debootstrap</a> - maintainer's decision on enabling "merged /usr" by default on newly - installed systems. The decision also clarified the desirable - solution on "merged /usr" status at the time of Debian - Bullseye's release.</li> - <li> - <a href="https://lists.debian.org/debian-devel-announce/2018/11/msg00004.html">2018-11-13</a> - <a href="https://bugs.debian.org/904302">Bug #904302:</a>The - technical committee decided that any use of dpkg's vendor-specific - patch series feature is a bug for packages in the Debian archive - and such feature will be forbidden in the Debian archive after the - release of Debian Buster.</li> - <li> - <a href="https://lists.debian.org/debian-devel-announce/2018/02/msg00004.html">2018-02-16</a> - <a href="https://bugs.debian.org/883573">Bug #883573:</a>The - technical committee repeals the decision made on 2014-11-15 in - <a href="https://bugs.debian.org/746578">Bug #746578</a> and - set the libpam-systemd package's dependencies free from - specific ordering constraints.</li> - <li> - <a href="https://lists.debian.org/debian-devel-announce/2017/07/msg00006.html">2017-07-31</a> - <a href="https://bugs.debian.org/862051">Bug #862051:</a>The - technical committee repeals the decision made on 2012-07-12 in - <a href="https://bugs.debian.org/614907">Bug #614907</a> and - allows nodejs package to provide /usr/bin/node in - backwards-compatibility arrangements.</li> - <li>2015-09-04 - <a href="https://bugs.debian.org/741573">Bug #741573:</a>The - technical committee adopts the changes to policy regarding menu - entries proposed by Charles Plessy, and additionally resolves that - packages providing desktop files shall not also provide a menu - file.</li> -<li>2015-06-19 - <a href="https://bugs.debian.org/750135">Bug #750135:</a>The - technical committee encourages Christian Perrier to implement his - proposal for maintenance of the Aptitude project.</li> -<li>2014-11-15 - <a href="https://bugs.debian.org/746578">Bug #746578:</a>The -committee decided that systemd-shim should be the first listed -alternative dependency of libpam-systemd instead of systemd-sysv.</li> -<li>2014-08-01 - <a href="https://bugs.debian.org/746715">Bug #746715</a>: The -technical committee expects maintainers to continue to support the -multiple available init systems.</li> -<li>2014-08-01 - <a href="https://bugs.debian.org/717076">Bug #717076</a>: The -committee decided that the default libjpeg implementation should be -libjpeg-turbo.</li> -<li>2014-02-11 - <a href="https://bugs.debian.org/727708">Bug #727708</a>: The -committee decided that the default init system for Linux architectures -in jessie should be systemd.</li> -<li>2013-03-06 - <a href="https://bugs.debian.org/698556">Bug #698556</a>: The -committee overrules the maintainer of isdnutils to require the -inclusion of code to create isdn devices by isdnutils.</li> -<li>2012-12-21 - <a href="https://bugs.debian.org/688772">Bug #688772</a>: - The committee overrules the dependency of meta-gnome - on network-manager while concerns raised in <a - href="https://bugs.debian.org/681834#273">§4 of the - decision in #681834</a> remain unaddressed.</li> -<li>2012-10-05 - <a href="https://bugs.debian.org/573745">Bug #573745</a>: - The committee declines to change the maintainer - of python packages in Debian.</li> -<li>2012-09-14 - <a href="https://bugs.debian.org/681834">Bug #681834</a>: gnome-core - should Recommends: network-manager; override maintainer.</li> -<li>2012-08-24 - <a href="https://bugs.debian.org/681783">Bug #681783</a>: Policy on - Recommends is correct; Recommends is fine in metapackages.</li> -<li>2012-08-14 - <a href="https://bugs.debian.org/681687">Bug #681687</a>: - evince's lack of mime type entry for PDF is RC bug - (decline to overrule release team).</li> -<li>2012-07-12 - <a href="https://bugs.debian.org/614907">Bug #614907</a>: - nodejs must use /usr/bin/nodejs, node must change - to ax25-node and provide /usr/sbin/ax25-node, and - transition packages and legacy packages defined.</li> -<li>2012-04-05 - <a href="https://bugs.debian.org/640874">Bug #640874</a>: decline to - override policy maintainers. debian/rules must be a Makefile.</li> -<li>2012-03-21 - <a href="https://bugs.debian.org/629385">Bug #629385</a>: - dpkg-buildpackage will implement build-arch testing using make -qn.</li> -<li>2012-02-27 - <a href="https://bugs.debian.org/607368">Bug #607368</a>: decline to - override the kernel maintainer team's ABI numbering policy.</li> -<li>2012-02-05 - <a href="https://bugs.debian.org/658341">Bug #658341</a>: multi-arch - enabled dpkg may be uploaded to experimental and unstable by Raphaël - Hertzog without waiting for primary maintainer code review.</li> -<li>2010-12-01 - <a href="https://bugs.debian.org/587886">Bug #587886</a>: - lilo should remain in unstable. Matt Arnold and Joachim - Wiedorn are to be joint maintainers of lilo.</li> -<li>2009-09-04 - <a href="https://bugs.debian.org/535645">Bug #535645</a>: - decline to override ftp team's removal of ia32-libs-tools; - reaffirm ftp team's ability to remove packages; - recommend clarification of reasons for removal, - and mechanism of reintroduction to the archive.</li> -<li>2009-08-27 - <a href="https://bugs.debian.org/510415">Bug #510415</a>: - allow Qmail into Debian after fixing delayed-bounce - issue with RC bug to block transition for one month</li> -<li>2009-07-30 - <a href="https://bugs.debian.org/539158">Bug #539158</a>: refuse to - override udev maintainer; printf suggested to be documented as a - required builtin in policy.</li> -<li>2009-07-25 - <a href="https://bugs.debian.org/484841">Bug #484841</a>: by - default, /usr/local is not writable by group staff; change can be - implemented after transition plan which enables administrators to - keep the current behavoir.</li> -<li>2007-12-10 - <a href="https://bugs.debian.org/412976">Bug #412976</a>: - keep current behavior and existing policy regarding mixmaster's use of /etc/default.</li> - -<li>2007-06-22 - <a href="https://bugs.debian.org/367709">Bug #367709</a>: - a libstdc++ udeb should not be created.</li> - -<li>2007-06-19 - <a href="https://bugs.debian.org/341839">Bug #341839</a>: - the output of <code>md5sum</code> should not change.</li> - -<li>2007-04-09 - <a href="https://bugs.debian.org/385665">Bug #385665</a>: - <code>fluidsynth</code> remains in main.</li> - -<li>2007-04-09 - <a href="https://bugs.debian.org/353277">Bug #353277</a>, - <a href="https://bugs.debian.org/353278">Bug #353278</a>: - <code>ndiswrapper</code> remains in main.</li> - -<li>2007-03-27 - <a href="https://bugs.debian.org/413926">Bug #413926</a>: - <code>wordpress</code> should be included in etch.</li> - -<li>2004-06-24 - <a href="https://bugs.debian.org/254598">Bug #254598</a>: - <code>amd64</code> is a fine name for that architecture. - <a href="https://lists.debian.org/debian-ctte/2004/debian-ctte-200406/msg00115.html">Full text</a>. - In favour: Wichert, Raul, Guy, Manoj, Ian. - Voting period ended early; no other votes.</li> -<li>2004-06-05 - <a href="https://bugs.debian.org/164591">Bug #164591</a>, - <a href="https://bugs.debian.org/164889">Bug #164889</a>: - <code>md5sum </dev/null</code> should produce the bare md5sum value. - <a href="https://lists.debian.org/debian-ctte/2004/debian-ctte-200406/msg00032.html">Full text</a>. - In favour: Guy, Ian, Manoj, Raul. - No other votes.</li> -<li>2002-10-06 - <a href="https://bugs.debian.org/104101">Bug #104101</a>, - <a href="https://bugs.debian.org/123987">Bug #123987</a>, - <a href="https://bugs.debian.org/134220">Bug #134220</a>, - <a href="https://bugs.debian.org/161931">Bug #161931</a>: - The default kernel should have VESA framebuffer support included. - <a href="https://lists.debian.org/debian-ctte/2002/debian-ctte-200211/msg00043.html">Full text</a>. - In favour: Ian, Jason, Raul; against: Manoj. - No other votes.</li> -<li>2002-07-19 <a href="https://bugs.debian.org/119517">Bug #119517</a>: - Packages may sometimes contain binaries whose libraries are only - referred to in Suggests. - <a href="https://lists.debian.org/debian-ctte/2002/debian-ctte-200207/msg00017.html">Full - text</a>. In favour: Ian, Wichert; against: Bdale, - Manoj; no-one else voted and Ian used his casting vote.</li> -</ul> - -<p>NB that decisions from before the 1st of April 2002 are not yet -recorded here.</p> - -<h3>Formal nontechnical and procedural decisions</h3> - -<ul> -<li>2015-03-05 Approved Sam Hartman, Tollef Fog Heen and Didier Raboud as - candidates for the committee. - (<a href="https://lists.debian.org/debian-ctte/2015/03/msg00023.html">Full - text</a>. In favour: Don, Bdale, Andreas, Colin, Steve, Keith. - Appointment approved by the DPL 2015-03-08; - <a href="https://lists.debian.org/debian-devel-announce/2015/03/msg00003.html">Full - text</a>).</li> -<li>2013-11-07 Approved Keith Packard as member of the technical committee (<a href="https://lists.debian.org/debian-ctte/2013/11/msg00041.html">resolution</a>)</li> -<li>2011-08-24 Approved Colin Watson as member of the technical committee (<a href="https://lists.debian.org/debian-devel-announce/2011/08/msg00004.html">for appointment</a>)</li> -<li>2009-01-11 Approved Russ Allbery and Don Armstrong as members of the technical committee (<a href="https://lists.debian.org/debian-ctte/2009/01/msg00053.html">summary</a>)</li> -<li>2006-04-11 Elected Bdale as chair (<a href=https://lists.debian.org/debian-ctte/2006/04/msg00042.html>for vote</a>)</li> -<li>2006-02-27 Elected Steve as chair (<a href=https://lists.debian.org/debian-ctte/2006/02/msg00085.html>for summary</a>)</li> -<li>2005-12-20 Approved Steve Langasek, Anthony Towns and Andreas Barth - as candidates for the committee. - (<a href="https://lists.debian.org/debian-ctte/2005/12/msg00042.html">Full - text</a>. In favour: Bdale, Manoj. Expressions of support, - with apologies, after end of the voting period: Ian, Raul. - None against or abstaining; Appointment approved by the DPL 2006-01-05; - <a href="https://lists.debian.org/debian-project/2006/01/msg00013.html">Full - text</a>).</li> -<li>2005-12-20 Proposed the removal of Wichert, Guy, and Jason - from the committee. - (<a href="https://lists.debian.org/debian-ctte/2005/12/msg00000.html">Motion text</a>; <a href="https://lists.debian.org/debian-ctte/2005/12/msg00028.html">results</a>. In favour: Manoj, Raul. Guy: in favour of his own removal; no opinion otherwise. Ian: in favour of removal of Jason; against otherwise. - Removal approved by the DPL 2006-01-05; - <a href="https://lists.debian.org/debian-project/2006/01/msg00013.html">Full - text</a>.)</li> -<li>2002-07-05 Passed the question of proper use of bug system - severities (<a href="https://bugs.debian.org/97671">Bug #97671</a>) - on to the BTS admins and project leader. - (<a href="https://lists.debian.org/debian-ctte/2002/debian-ctte-200207/msg00002.html">Full - text</a>. In favour: Ian, Jason, Bdale; none against or abstaining.)</li> - -<li>2002-01-31 Appointed Ian Jackson as chairman, following Raul's - resignation from the post. (In favour: Dale, Ian, Manoj, Raul, Wichert; - none against or abstaining.)</li> - -</ul> - -<p>NB that decisions from before the 31st of January 2002 are not yet -recorded here.</p> - -<toc-add-entry name="retiredmembers">Retired members</toc-add-entry> - -Thanks to the following people who have served on the committee: - -<ul> -<li>Phil Hands (2016-04-16 - 2020-12-31)</li> -<li>Tollef Fog Heen (2015-03-05 - 2019-12-31)</li> -<li>Didier Raboud (2015-03-05 - 2019-12-31)</li> -<li>Keith Packard (2013-11-29 - 2017-12-31)</li> -<li>Sam Hartman (2015-03-08 - 2017-11-09)</li> -<li>Don Armstrong (2009-09-11 - 2016-12-31)</li> -<li>Andreas Barth (2006-01-04 - 2016-12-31)</li> -<li>Steve Langasek (2006-01-04 - 2015-12-31)</li> -<li>Bdale Garbee (2001-04-17 - 2015-12-31)</li> -<li>Colin Watson (2011-08-24 - 2015-03-05)</li> -<li>Ian Jackson (to 2014-11-19)</li> -<li>Russ Allbery (2009-01-11 - 2014-11-16)</li> -<li>Manoj Srivasta (to 2012-08-12)</li> -<li>Anthony Towns (2006-01-04 - 2009-01-05)</li> -<li>Raul Miller (to 2007-04-30)</li> -<li>Wichert Akkerman (to 2006-01-05)</li> -<li>Jason Gunthorpe (to 2006-01-05)</li> -<li>Guy Maor (to 2006-01-05)</li> -<li>Dale Scheetz (to 2002-09-02)</li> -<li>Klee Dienes (to 2001-05-21)</li> - -</ul> diff --git a/greek/devel/testing.wml b/greek/devel/testing.wml deleted file mode 100644 index 64176b6f9ee..00000000000 --- a/greek/devel/testing.wml +++ /dev/null @@ -1,320 +0,0 @@ -#use wml::debian::template title="Debian “testing” distribution" BARETITLE=true -#include "$(ENGLISHDIR)/releases/info" -#use wml::debian::translation-check translation="8900568ad5473cc15ea75f71f489b4f2b7ae659e" maintainer="galaxico" - -<p>For basic, user-oriented information about the testing distribution, -please see <a href="$(DOC)/manuals/debian-faq/ftparchives#testing">the Debian FAQ</a>.</p> - -<p>An important thing to note, both for regular users and the developers of -testing, is that security updates for testing are <strong>not managed by -the security team</strong>. For more information please see the -<a href="../security/faq#testing">Security Team's FAQ</a>.</p> - -<p>This page primarily covers the aspects of <q>testing</q> important to Debian -developers.</p> - -<h2>How <q>testing</q> works</h2> - -<p>The <q>testing</q> distribution is an automatically generated distribution. -It is generated from the <q>unstable</q> distribution by a set of scripts which -attempt to move over packages which are reasonably likely to lack release-critical -bugs. They do so in a way that ensures that dependencies of other packages -in testing are always satisfiable.</p> - -<p>A (particular version of a) package will move into testing when it -satisfies all of the following criteria:</p> - -<ol> - <li>It must have been in unstable for 10, 5 or 2 days, depending on the - urgency of the upload;</li> - - <li>It must be compiled and up to date on all architectures it has - previously been compiled for in unstable;</li> - - <li>It must not have release-critical bugs which do not also apply to - the version currently in <q>testing</q> (see below for - <a href="#faq">more information</a>);</li> - - <li>All of its dependencies must <em>either</em> be satisfiable by - packages already in <q>testing</q>, <em>or</em> be satisfiable by the group - of packages which are going to be installed at the same time;</li> - - <li>The operation of installing the package into <q>testing</q> must not break - any packages currently in <q>testing</q>. (See below for - <a href="#faq">more information</a>.)</li> -</ol> - -<p>A package which satisfies the first three of the above is said to be a -<q>Valid Candidate</q>.</p> - -<p>The update script shows when each package might move from <q>unstable</q> into -<q>testing</q>. The output is twofold:</p> - -<ul> - <li>The <a href="https://release.debian.org/britney/update_excuses.html">\ - update excuses</a> - [<a href="https://release.debian.org/britney/update_excuses.html.gz">\ - gzipped</a>]: - list of all candidate package versions and the basic status of their - propagation into <q>testing</q>; this is somewhat shorter and nicer than - </li> - <li>The <a href="https://release.debian.org/britney/update_output.txt">\ - update output</a> - [<a href="https://release.debian.org/britney/update_output.txt.gz">\ - gzipped</a>]: - the complete, rather crude output of the <q>testing</q> scripts as they - recurse through the candidates - </li> -</ul> - -<h2><a name="faq">Frequently Asked/Answered Questions</a></h2> - -# Note to translators: these two first items are almost the same as -# https://www.debian.org/doc/manuals/developers-reference/pkgs.html#faq - -<h3><q>What are release-critical bugs, and how do they get counted?</q></h3> - -<p>All bugs of some higher severities are by default considered -<em><a href="https://bugs.debian.org/release-critical/">release-critical</a></em>; -currently, these are <strong>critical</strong>, <strong>grave</strong> and -<strong>serious</strong> bugs.</p> - -<p>Such bugs are presumed to have an impact on the chances that the package -will be released with the stable release of Debian: in general, if a package -has open release-critical bugs filed on it, it won't get into <q>testing</q>, and -consequently won't be released in <q>stable</q>.</p> - -<p> -The <q>testing</q> bug count are all release-critical bugs which -are marked to apply to <tt>package/version</tt> combinations -that are available in <q>testing</q>for a release architecture. -</p> - - -<h3><q>How could installing a package into <q>testing</q> possibly break other -packages?</q></h3> - -<p>The structure of the distribution archives is such that they can only -contain one version of a package; a package is defined by its name. So, when -the source package <tt>acmefoo</tt> is installed into <q>testing</q>, along with -its binary packages <tt>acme-foo-bin</tt>, <tt>acme-bar-bin</tt>, -<tt>libacme-foo1</tt> and <tt>libacme-foo-dev</tt>, the old version is -removed.</p> - -<p>However, the old version may have provided a binary package with an old -soname of a library, such as <tt>libacme-foo0</tt>. Removing the old -<tt>acmefoo</tt> will remove <tt>libacme-foo0</tt>, which will break any -packages which depend on it.</p> - -<p>Evidently, this mainly affects packages which provide changing sets of -binary packages in different versions (in turn, mainly libraries). However, -it will also affect packages upon which versioned dependencies have been -declared of the ==, <= or << varieties.</p> - -<p>When the set of binary packages provided by a source package change in -this way, all the packages that depended on the old binaries will have to be -updated to depend on the new binaries instead. Because installing such a -source package into <q>testing</q> breaks all the packages that depended on it in -<q>testing</q>, some care now has to be taken: all the depending packages must be -updated and ready to be installed themselves so that they won't be broken, -and, once everything is ready, manual intervention by the release manager or -an assistant is normally required.</p> - -<p>If you are having problems with complicated groups of packages like this, -contact debian-devel or debian-release for help.</p> - -<h3><q>I still don't understand! The <q>testing</q> scripts say that this -package is a valid candidate, but it still hasn't gone into -<q>testing</q>.</q></h3> - -<p>This tends to happen when in some way, directly or indirectly, installing -the package will break some other package.</p> - -<p>Remember to consider your package's dependencies. Suppose your package -depends on libtool, or libltdl<var>X</var>. Your package won't go into -<q>testing</q> until the right version of libtool is ready to go in with it.</p> - -<p>In turn, that won't happen until installing libtool doesn't break things -already in <q>testing</q>. In other words, until all other packages which depend -on libltdl<var>Y</var> (where <var>Y</var> is the earlier version) have been -recompiled, and all their release critical bugs are gone, etc, none of these -packages will enter <q>testing</q>.</p> - -<p>This is where the <a href="https://release.debian.org/britney/update_output.txt">\ -textual output</a> -[<a href="https://release.debian.org/britney/update_output.txt.gz">gzipped</a>] -is useful: it gives hints (albeit very terse ones) as to which packages -break when a valid candidate is added to <q>testing</q> (see the <a -href="$(DOC)/manuals/developers-reference/pkgs.html#details">\ -Developer's Reference for more details</a>). -</p> - -<h3><q>Why is it sometimes hard to get <kbd>Architecture: all</kbd> packages -into <q>testing</q>?</q></h3> - -<p>If the <kbd>Architecture: all</kbd> package is to be installed, it must -be possible to satisfy its dependencies on <strong>all</strong> -architectures. If it depends on certain packages which only compile on a -limited set of Debian's architectures, then it can't do that.</p> - -<p>However, for the time being, <q>testing</q> will ignore <kbd>Architecture: -all</kbd> packages' installability on non-i386 architectures. (<q>It's a -gross hack and I'm not really happy to have made it, but there you go.</q> -—aj)</p> - -<h3><q>My package is stalled because it's out of date on some architecture. -What do I do?</q></h3> - -<p>Check the status of your package in the -<a href="https://buildd.debian.org/build.php">build log database</a>. -If the package doesn't build, it will be marked as <em>failed</em>; -investigate the build logs and fix any of the problems that are caused -by your package's sources.</p> - -<p>If you happen to notice that some architectures have built the new -version of your package, but it isn't showing up in <q>testing</q> scripts output, -then you just have to be a bit more patient until the respective buildd -maintainer uploads the files to the Debian archive.</p> - -<p>If you notice that some architectures haven't built your new version of -the package at all, despite the fact you uploaded a fix for an earlier -failure, the reason is probably that it's marked as waiting for dependencies -(Dep-Wait). You can also see the list of these so-called -<a href="https://buildd.debian.org/stats/">wanna-build states</a> to make -sure.</p> - -<p>These problems usually get fixed eventually, but if you've been waiting -for a longer period of time (say, two weeks or more), notify the respective -port buildd maintainer if such an address is documented on the -<a href="$(HOME)/ports/">port web page</a>, or the mailing list of the -port.</p> - -<p>If you have explicitly dropped the architecture from the Architecture list -in the control file, and the package has been built for that architecture -before, you will need to request that the old binary package for this -architecture be removed from the archive before your package can transition to -testing. You need to file a bug against <q>ftp.debian.org</q> requesting removal of -the dropped architecture's packages from the unstable archive. Generally the -relevant porting list should be informed as a matter of courtesy.</p> - -<h3><q>Are there any exceptions? I'm sure <tt>acmefoo</tt> has just made -it into <q>testing</q> despite not satisfying all of the requirements.</q></h3> - -<p>The release manager can override the rules in two ways:</p> - -<ul> - <li>They can decide that the breakage caused by the installation of a new - library will make things better rather than worse, and let it go in - along with its flotilla of dependents.</li> - <li>They can also manually remove packages from <q>testing</q> that would be - broken, so that new stuff can be installed.</li> -</ul> - -<h3><q>Can you provide a real, non-trivial example?</q></h3> - -<p>Here's one: when the source package <tt>apache</tt> is installed into -<q>testing</q>, along with its binary packages <tt>apache</tt>, -<tt>apache-common</tt>, <tt>apache-dev</tt> and <tt>apache-doc</tt>, the -old version is removed.</p> - -<p>However, all Apache module packages depend on <code>apache-common (>= -<var>something</var>), apache-common (<< <var>something</var>)</code>, -so this change breaks all of those dependencies. Consequently, all Apache -modules need to be recompiled against the new version of Apache in order -for <q>testing</q> to be updated.</p> - -<p>Let's elaborate on this a bit further: after all of the modules have been -updated in unstable to work with a new Apache, the <q>testing</q> scripts try -<tt>apache-common</tt> and find out that it breaks all the Apache modules -because they have <code>Depends: apache-common (<< <var>the current -version</var>)</code>, and then try <tt>libapache-<var>foo</var></tt> to find -out that it doesn't install because it has <code>Depends: apache-common (>= -<var>the new version</var>)</code>.</p> - -<p>However, later they'll apply a different logic (sometimes prompted by a -manual intervention): they'll ignore the fact <tt>apache-common</tt> breaks -stuff, and keep going with things that work; if it still doesn't work after -we've done everything we can, too bad, but maybe it <strong>will</strong> -work. Later they'll try all the random <tt>libapache-<var>foo</var></tt> -packages and see that they indeed work.</p> - -<p>After everything's been tried, they check how many packages have been -broken, work out if that's better or worse than what there was originally -and either accept everything or forget about it. You'll see this in -<tt>update_output.txt</tt> on <q><code>recur:</code></q> lines.</p> - -<p>For example:</p> - -<pre> - recur: [<var>foo</var> <var>bar</var>] <var>baz</var> -</pre> - -<p>basically says <q>having already found that <var>foo</var> and -<var>bar</var> make things better, I'm now trying <var>baz</var> to -see what happens, even though that breaks things</q>. The lines of -<tt>update_output.txt</tt> that start with <q><code>accepted</code></q> indicate -things that appear to make things better, and <q><code>skipped</code></q> lines make -things worse.</p> - -<h3><q>The <tt>update_output.txt</tt> file is completely unreadable!</q></h3> - -<p>That is not a question. ;-)</p> - -<p>Let's take an example:</p> - -<pre> - skipped: cln (0) (150+4) - got: 167+0: a-40:a-33:h-49:i-45 - * i386: ginac-cint, libginac-dev -</pre> - -<p>This means that if <tt>cln</tt> goes into <q>testing</q>, <tt>ginac-cint</tt> -and <tt>libginac-dev</tt> become uninstallable in <q>testing</q> on i386. -Note that the architectures are checked in alphabetical order and only the -problems on the first architecture with problems are shown — that's why -the alpha architecture is shown so often.</p> - -<p>The <q>got</q> line includes the number of problems in <q>testing</q> on the -different architectures (until the first architecture where a problem is -found — see above). The <q>i-45</q> means that if <tt>cln</tt> would go into -<q>testing</q>, there would be 45 uninstallable packages on i386. Some of the -entries above and below <tt>cln</tt> show there were 43 uninstallable -packages in <q>testing</q> on i386 at the time.</p> - -<p>The <q>skipped: cln (0) (150+4)</q> line means that there are still 150 -packages to go through after this package until this check of all packages -is completed, and that 4 packages have been found already that won't be -planned to be upgraded because they would break dependencies. The <q>(0)</q> is -irrelevant, you can safely ignore it.</p> - -<p>Note that there are several checks of all packages in one <q>testing</q> -script run.</p> - -<p><em>Jules Bean initially assembled the frequently asked questions and -answers.</em></p> -# Created: Sat Dec 8 12:44:29 GMT 2001 - -<h2>Additional information</h2> - -<p>The following pages provide additional information about the current state -of testing and the migration of packages from unstable to testing:</p> - -<ul> -<li>Statistics on binary packages that are out of date for -<a href="https://release.debian.org/britney/testing_outdate.txt">testing</a>, -<a href="https://release.debian.org/britney/stable_outdate.txt">stable</a> -<li>Dependency problems in -<a href="https://qa.debian.org/debcheck.php?list=INDEX&dist=testing">testing</a>, -<a href="https://qa.debian.org/debcheck.php?list=INDEX&dist=stable">stable</a> -</ul> - -<p>You might be interested in reading an older -<a href="https://lists.debian.org/debian-devel-0008/msg00906.html">explanation -email</a>. Its only major flaw is that it doesn't take the package pool -into account, because that was implemented by James Troup after it was -written.</p> - -<p>The testing code is available from -<a href="https://release.debian.org/britney/update_out_code/">ftp-master</a>.</p> - -<p><em>Anthony Towns takes credit for the implementation of testing.</em></p> diff --git a/greek/devel/website/content_negotiation.wml b/greek/devel/website/content_negotiation.wml deleted file mode 100644 index 0ff8203631f..00000000000 --- a/greek/devel/website/content_negotiation.wml +++ /dev/null @@ -1,31 +0,0 @@ -#use wml::debian::template title="Content Negotiation" -#use wml::debian::translation-check translation="c646e774c01abc2ee3d32c65d6920ea4f03159dc" maintainer="galaxico" - -<H3>How Does the Server Know Which File to Serve</H3> -<P>You will notice that internal links don't end in .html. This -is because the server is using content negotiation to decide -which version of the document to deliver. When there is more -than one choice, the server will make a list of all possible -files to serve, e.g. if the request is for 'about', then the list -of completions might be about.en.html and about.de.html. -The default for Debian servers will be to serve the English -document, but it is configurable. - -<P>If a client has the proper variable set, for example to serve German, -then in the example above about.de.html would be served. The -nice thing about this setup is that if the desired language is -not available, a different language will be delivered instead -(which hopefully is better than nothing). The decision on which -document is served is a bit confusing so instead of describing -it here, you should get the definitive answer from -<a href="https://httpd.apache.org/docs/current/content-negotiation.html">https://httpd.apache.org/docs/current/content-negotiation.html</a> -if you are interested. - -<P>Because many users will not even know of the existence of content-negotiation, -there are links at the bottom of every page pointing directly -to the version of that page in every other language available. -This is computed using a perl script called by wml when the -page is generated. - -<P>There is also an option to override the browser language preferences -using a cookie that prioritises a single language over the browser preferences. diff --git a/greek/devel/website/desc.wml b/greek/devel/website/desc.wml deleted file mode 100644 index 42f731e7468..00000000000 --- a/greek/devel/website/desc.wml +++ /dev/null @@ -1,176 +0,0 @@ -#use wml::debian::template title="How is www.debian.org made" -#use wml::debian::toc -#use wml::debian::translation-check translation="6d9ec7201dcfa229e0cdf7f93c34b3d4a8509ebe" maintainer="galaxico" - -<p>The Debian <em>“webtree”</em>, collection of directories and files -that comprise our web site, is located in the <tt>/org/www.debian.org/www</tt> -directory on www-master.debian.org. The bulk of the pages are normal static -HTML files (i.e. not produced with something dynamic such as a CGI or a PHP -script), because the web site is mirrored. - -<p>The site is generated in one of three ways: -<ul> - <li>the bulk of it is generated using WML, from the - <a href="$(DEVEL)/website/using_git"><q>webwml</q> git repository</a> - <li>the documentation is generated either using DocBook XML (use of DebianDoc - SGML is being phased out), from the - <a href="$(DOC)/vcs"><q>ddp</q> git repository</a>; or - using <a href="#scripts">cron scripts</a>, from the corresponding - Debian packages - <li>parts of the site are generated using scripts using other sources, - e.g. the mailing list (un)subscription pages -</ul> - -<p>An automatic update (from the git repository and other sources to the -webtree) is being run six times a day. - -<p>If you'd like to contribute to the site, do <strong>not</strong> simply -add to or edit items in the <code>www/</code> directory. Contact -<a href="mailto:webmaster@debian.org">the webmasters</a> first. - -<p>All the files and directories are owned by group debwww and writable -by that group, so the web team can modify files in the web directory. The -2775 mode on directories means that any files created under that directory -will inherit the group - debwww in this case. Anyone in group debwww is -expected to set '<code>umask 002</code>' so that the files are created with -group write permissions. - -<toc-display /> - -<hrline /> - - -<toc-add-entry name="look">Look & feel</toc-add-entry> - -<p>We give the pages the same look and feel by having -<a href="https://packages.debian.org/unstable/web/wml">WML</a> do all -the detail work of adding headers and footers to pages. Although a .wml page -may look like HTML at first glance, HTML is only one of the types of extra -information that can be used in .wml. After WML is finished running its various -filters over a file, the final product is true HTML. To give you an idea of -the power of WML, you can include Perl code into a page to allow you to do, -well, almost anything. - -<p>Note however that WML checks (and sometimes automagically corrects) only -the very basic validity of your HTML code. You should install -<a href="https://packages.debian.org/unstable/web/weblint">weblint</a> -and/or -<a href="https://packages.debian.org/unstable/web/tidy">tidy</a> -to validate your HTML code. - -<p>Our web pages currently comply to the -<a href="http://www.w3.org/TR/html4/">HTML 4.01 Strict</a> standard. - -<p>Anyone who is working on a lot of pages should install WML so they can -test to make sure the result is what they want. If you are running Debian, -you can easily install the <code>wml</code> package. Read the pages on -<a href="using_wml">using WML</a> for more information. - - -<toc-add-entry name="sources">Sources</toc-add-entry> - -<p>The source for the web pages is stored under git. git is a version -control system, which allows us to keep a log of which, who, when, and why changes -occurred, etc. It is a safe way to control the concurrent editing of source -files among multiple authors, which is crucial for us because the Debian web -team is rather large in size. - -<p>If you are unfamiliar with this program, you will want to read the pages -on <a href="using_git">using git</a>. - -<p>The topmost webwml directory in the git repository contains directories -named after the languages the web site is in, two makefiles and several -scripts. The translation directory names should be in English and lowercase -(e.g. "german", not "Deutsch"). - -<p>The more important of the two makefiles is Makefile.common, which, as its -name says, contains some common rules which are applied by including this -file in the other makefiles. - -<p>Each of the language directories contains makefiles, WML source files and -subdirectories. The file and directory names do not differ in order to keep -the links correct for all languages. The directories may also contain .wmlrc -files which contain some information useful to WML. - -<p>The webwml/english/template directory contains special WML files that we -call templates, because they can be referenced from all other files using the -<code>#use</code> command. - -<p>In order for changes in the templates to propagate to the files which use -them, the files have makefile dependencies on them. Since a vast majority of -the files use the "template" template, by having a -"<code>#use wml::debian::template</code>" line at the top, the generic -dependency (the one for all files) is that very template. There are -exceptions to this rule, of course. - - -<toc-add-entry name="scripts">Scripts</toc-add-entry> - -<p>The scripts are mostly written in shell or Perl. Some of them are -standalone, and some of them are integrated into WML source files.</p> - -<p>The sources for the main www-master rebuild scripts are in the -<a href="https://salsa.debian.org/webmaster-team/cron.git">webmaster-team/cron -Git repository</a>. -</p> - -<p>The sources for the packages.debian.org rebuild scripts are in the -<a href="https://salsa.debian.org/webmaster-team/packages">webmaster-team/packages -Git repository</a>.</p> - - -<toc-add-entry name="help">How to help</toc-add-entry> - -<p>We invite everyone interested to help us make the Debian site as good as -it can be. If you have valuable information related to Debian that you think -our pages are missing, <a href="mailto:debian-www@lists.debian.org">share it -with us</a> and we'll see that it gets included. - -<p>We could always use help with designing pages (regarding graphics and -layouts), and keeping our HTML clean, too. We regularly run the following -checks on the whole web site:</p> - -<ul> - <li><a href="https://www-master.debian.org/build-logs/urlcheck/">URL check</a> - <li><a href="https://www-master.debian.org/build-logs/validate/">wdg-html-validator</a> - <li><a href="https://www-master.debian.org/build-logs/tidy/">tidy</a> -</ul> - -<p>Help is always welcome in reading the above logs and fixing the problems.</p> - -<p>The current build logs for the web site can be found at -<url "https://www-master.debian.org/build-logs/">.</p> - -<p>If you're a fluent English speaker, we'd like you to proof-read our pages -and report all errors to <a href="mailto:debian-www@lists.debian.org">us</a>. - -<p>If you speak another language, you may want to help us translate the -pages to your language. If a translation has already been made, but has -problems, take a look at the list of <a href="translation_coordinators">\ -translation coordinators</a> and talk to the leader for your language -about fixing it. If you'd like to translate pages yourself, see the page on -<a href="translating">that topic</a> for more information. - -<p>There's also a <a href="todo">TODO file</a>, check it out.</p> - - -<toc-add-entry name="nohelp">How <strong>not</strong> to help</toc-add-entry> - -<p><em>[Q] I want to put <var>fancy web feature</var> into www.debian.org, -may I?</em> - -<p>[A] No. We want www.debian.org to be as accessible as possible, so -<ul> - <li>no browser specific "extensions". - <li>no relying on images only. Images may be used to clarify, but the - information on www.debian.org must remain accessible via a text-only - web browser, like lynx. -</ul> - -<p><em>[Q] I have this nice idea. Can you enable FOO in www.debian.org's -HTTPD, please?</em> - -<p>[A] No. We want to make life easy for administrators to mirror -www.debian.org, so no special HTTPD features please. No, not even SSI. -An exception has been made for content negotiation. This is because it -is the only robust way to serve multiple languages. diff --git a/greek/devel/website/errors/404.wml b/greek/devel/website/errors/404.wml deleted file mode 100644 index 7a19f95d611..00000000000 --- a/greek/devel/website/errors/404.wml +++ /dev/null @@ -1,10 +0,0 @@ -#use wml::debian::template title="Page not found" -#use wml::debian::translation-check translation="1fed65f277a53d12839ebbf4454d9f7ea9fca5ed" maintainer="galaxico" - -<p>We are sorry, the page you were looking for can't be found on this site. -Please inform the site owner that referred you to this page about the broken -link. You can go to the <a href="$(HOME)">home page of the Debian project</a> in the -meantime or use the <a href="$(SEARCH)">search engine</a> to crawl the website for the -information you are looking for.</p> - - diff --git a/greek/devel/website/errors/Makefile b/greek/devel/website/errors/Makefile deleted file mode 100644 index c26323c0c92..00000000000 --- a/greek/devel/website/errors/Makefile +++ /dev/null @@ -1 +0,0 @@ -include $(subst webwml/greek,webwml/english,$(CURDIR))/Makefile diff --git a/greek/devel/website/htmlediting.wml b/greek/devel/website/htmlediting.wml deleted file mode 100644 index 1a4673df9ef..00000000000 --- a/greek/devel/website/htmlediting.wml +++ /dev/null @@ -1,141 +0,0 @@ -#use wml::debian::template title="Debian Web Pages HTML Usage" BARETITLE=true -#use wml::debian::common_tags -#use wml::debian::acronyms -#use wml::debian::toc -#use wml::debian::translation-check translation="648de6ad5bea60540e41a5733da0b761a34c7927" maintainer="galaxico" - -<p> -This page is still a draft. -</p> - -<toc-display/> - -<toc-add-entry name="preface">Preface</toc-add-entry> - -<p>This page is built to help editors and translators to form well-tagged pages. -It contains hints about tag usage and how to create new pages and make them -more easy to translate.</p> - - -<toc-add-entry name="general">Some general hints</toc-add-entry> -<p>For new pages or translations here's a list of general advice</p> -<dl> -<dt>do not use long lines</dt> -<dd> -The wml files and other files should have lines fitting in a normal -terminal window. This is easier to edit in vi, better searchable and -easier to translate. It's also important because -it's harder to resolve conflicts in long lines. -</dd> -<dt>keep tags in separate lines if possible</dt> -<dd> -Most HTML tags can be kept in separate lines. Some of them are <div>, -<p>, <table>, <ul>. To make things easier for translators, -you should keep all tags that can be used this way in separate lines. Otherwise -translators may delete tags accidentally and forget to restore -them after translating. -</dd> -<dt>do not use spaces or line breaks in inline tags</dt> -<dd>Some tags produce a space, if they are kept in separate lines. One of those -is the <q>tag for small citations or quotes. You may only separate them -as a whole with content in one line. Else there might be a space between content -and tag in the HTML page afterwards. Between words in these tags you may -have as many line breaks or spaces as you want. -</dd> -</dl> - -<toc-add-entry name="abbreviations">Abbreviations and Acronyms</toc-add-entry> -<p> -For abbreviations and acronyms the HTML tag <acronym> should be used. -There are two reasons why the use of the <abbr> tag is not recommended: -First not all -browsers do support it and second there are inconsistent definitions about what -is an acronym and what is an abbreviation. -</p> -<p> -An acronym is added to the page in the following syntax: -<code><acronym lang="language code" title="Full definition of -acronym">ACRONYM</acronym></code>. The title contains the full spoken -words. If the acronym is built from initial letters of words, those letters -should be upper case in the title. The lang attribute is only needed if the -acronym or abbreviation is in a foreign language. -</p> -<p> -There is already a set of common acronyms in the wml templates -included to use it in your page, you have to add a line to use -<code>acronyms</code> in the wml file. For example the wml tag for DD is -<acronym_DD />. -</p> - -<toc-add-entry name="citations">Citations and Quotes</toc-add-entry> -<p> -There are several different rules what a citation or quote is for different -languages. If you have a short inline citation you have to use the <q> -tag. -The rendering of the content is handled by language CSS. <q> tags must -not have a space or line break between the opening and closing tag and the -content. -</p> -<p> -For longer citations the tag <blockquote> is used. A <blockquote> -encloses one or more paragraphs of text, which are marked with <p>. -Please do not use the <blockquote> tags for centering any block of text -which is not a citation. Blockquotes are exclusively for citations and will -be rendered by language specific CSS code in the future. -</p> -<p> -There is also a <cite> tag in HTML. The <cite> tag is not used for -the citation text itself. It is used for the source of a citation. This can be -the name of the person the citation is from and is added as attribute -to a <blockquote> as URL. -</p> - -<toc-add-entry name="code">Program Names and Code</toc-add-entry> -<p> -For program names and computer code there is a tag named <code>. Browsers -normally know about displaying code and program names, but rendering -can also be changed by CSS. It is not a good idea to use <tt> -instead as this does not say anything about the content. -</p> - -<toc-add-entry name="samp">Samples of Computer Output</toc-add-entry> -<p> -For computer output on the screen there is a special tag named <samp>. If -you have a larger block of computer output, you should also have -a look into the CSS file, if there is a special class for it. -</p> - -<toc-add-entry name="kbd">Keyboard Input</toc-add-entry> -<p>If there are examples where the user has to type something on the -keyboard, the <kbd> tag is used for the user input. See also the chapter -about <a href="#var">variables</a> for how to tag the variable input. -</p> - -<toc-add-entry name="var">Variables</toc-add-entry> -<p> -Sometimes it is necessary to emphasize a variable input such as -a special IP address or the users name which has to be -given in a program call on command line. For these variable inputs the <var> -tag is used. -</p> - -<toc-add-entry name="pre">Preformatted Content</toc-add-entry> -<p> -The <pre> tag is use for preformatted text only. Line length, spaces and -other things will be preserved. Naturally this tag cannot contain most -of the other HTML tags. -</p> - -<toc-add-entry name="img">Images</toc-add-entry> -<p> -If there are images added in the page, there is no need to add an invalid -border=0 as attribute. But if possible the image size and an <code>alt</code> attribute -should -be added. The size is added by wml if not present, but that needs compile -time. The <code>alt</code> attribute should contain something that tells users browsing -with lynx and blind people what is in the image. -</p> - - -# <toc-add-entry name=""></toc-add-entry> - diff --git a/greek/devel/website/todo.wml b/greek/devel/website/todo.wml deleted file mode 100644 index f9ced53d611..00000000000 --- a/greek/devel/website/todo.wml +++ /dev/null @@ -1,292 +0,0 @@ -#use wml::debian::template title="Debian Web Pages TODO List" BARETITLE=true -#use wml::debian::common_tags -#use wml::debian::toc -#use wml::debian::translation-check translation="4c1a7bf103f9b1ba7228b8356649c7dcb99f1cb2" maintainer="galaxico" - -# Note to translators: there should be no need to translate this file, -# unless you're some sort of masochistic psycho :) - -<toc-display/> - -<toc-add-entry name="important">Fairly important items</toc-add-entry> - -<h3>/donations and /partners/</h3> - - <P>Make a page for old donations, we don't want to forget the past ones, - but they'd clutter up the page of current donations. Same for partners. - - <p>Separate huge chunks of non-translatable data from the donations page. - See /mirror/sponsors for a start. - -<h3>/ports/</h3> - - <p>All port specific information should be in the port pages. - (More of a long-standing wishlist that can't ever be fixed. :) - - <p>Review the ports listed as unmaintained in the port.maintainers file - and fix them. - - <p>Import the sh port pages. - -<h3>/intro/about</h3> - - <P>This page should be shortened and have the more detailed information in - links. There has been a suggestion that we create an advocacy page with - links to other free projects that Debian supports. - - <P>One example is licenses. I [treacy?] wrote a bit about them, but it - really should be moved to its own page (see <tt>intro/license_disc.wml</tt>). - We need to convince people that some licenses are better than others. Hmmm - sounds like this should be linked from the advocacy page too. - - <P>Writing an intro to something like Debian is not an easy job. You - really need to give some thought into how you split up all the - (interconnected) issues involved. - -<h3>/intro/advocacy</h3> - - <P>A new page as mentioned above. The LPF needs to be linked from here - (this is what started the idea of an advocacy page). - - <P>This should probably be created only when someone has time to redo all - the intro documents. I [treacy?] have a lot of ideas on this and will do - it myself if I get enough time. - -<h3>/CD/vendors/</h3> - - <P>All the vendors web sites need to be checked to see that they actually - contribute. They should also be checked after each major release of Debian. - - <P>Another solution would be to move it to a database-driven system. - There's already some sort of an internal database that only Craig knows - about. - - <P><I>This page is being maintained by Craig Small (csmall@debian.org)</I> - -<h3>/consultants/index</h3> - - <p>This needs to be split up. (by continent, perhaps by country too) - -<h3>/events/*/</h3> - - <p>Too much redundant stuff is left in the files translators touch; the - same thing with .data files that we (treacy with some help from joy) did - to security/ should be done here. Plus, this would make a single location - where we change whether an event is past or current, which is a major - hassle. - -<h3>/doc/books</h3> - - <p>The tags for title, author, language, url, and available should be - separated from the translatable portion of the page. - -<h3>/vote/*/</h3> - - <p>Get the secretary to (help) maintain these pages. - - <p>Figure out if we should keep basic+votebar templates, instead of just - one template ("votepage" or something). - -<h3>packages.debian.org</h3> - - <p>You can find a current <a - href="https://salsa.debian.org/webmaster-team/packages/blob/master/TODO">TODO - list</a> in the <a - href="https://salsa.debian.org/webmaster-team/packages/">Git - repository</a>.</p> - - <p><i>The scripts are currently maintained by Frank 'djpig' Lichtenheld and - Martin 'Joey' Schulze.</i></p> - -<h3>/ports/hurd</h3> - - <p>Move this out of ports because they is not a Linux port (beowulf already removed). (Rename - /ports/, too?) - -<h3>/sitemap</h3> - - <p>Maybe we should emphasize some major pages by making them - <strong> or <em>. - -<h3>lists.debian.org</h3> - - <p>"We might want to put a note on lists.debian.org, pointing out that - Debian reserves the right to archive any mail that comes into Debian." - -- David Starner - - <p>There's now a note to that effect in /MailingLists/. - -<h3>/security/*/</h3> - - <p>Find the <moreinfo> entries for older years that contain mentions - of lists-archives instead of including text from it or even linking to it, - and correct it. - - <p>There are many advisories in 1997 and early 1998 that lack even the - basic extra information -- find it and document it. Somehow. :) - - <p>Change the pages to have 'fixed in' info in a tag instead of page body, - so that we can check for that tag in the template and not display 'Fixed - in:' if it's empty. - -<h3>/ports/i386/</h3> - - <p>Make the x86 port pages more useful... somehow :) - -<h3>/MailingLists/{,un}subscribe</h3> - - <p>Split it up by section? Perhaps, if it grows too much... - - <p>This is already partially remedied by having various - https://lists.debian.org/foo pages include a sub/unsub form. - - <p>Make a note about the anti-abuse check. - -<h3>/intro/organization</h3> - - <p>Collect remaining missing representatives of Debian in other places, - verify/maintain the current ones. - -<h3>/devel/website/*</h3> - - <p>Code all the remaining best current practices. - -<toc-add-entry name="cn">Content negotiation issues</toc-add-entry> - - <p>The content negotiation system has several flaws that might make some - people give up on our site. However, we can't do much about this. Most of - it is caused by clients sending non-RFC strings in the Accept-Language - header, which makes Apache go bezerk and apply some of its illogical - methods of serving smallest available files. - - <p>When given "*" in the Accept-Language header, the first available page - will be served, and that's most likely not English, rather Arabic or - Chinese. This is especially problematic when the user's language - preference is a two-part language code (like "en-ca" or "nl-BE") followed - by a "*". - - <p>Apache 1.3 sticks with the RFC here. Apache 2.0's code will imply a - en or nl respectively, but it will be low priority so it probably won't - help with e.g. "en-ca, fr-ca, *". - - <p>Also, when there exists a file of unknown language, i.e. an unrecognized - foo.*.html file with no AddLanguage or LanguagePriority setting, and when - the client sends an Accept-Language which contains only unavailable - languages, the former file will be served. - - <p>This happened most often with the /releases/potato/i386/install page, - because there's a Slovak variant of it and we didn't have that language - set up in Apache because there's no web site translation in Slovak. - We've alleviated the problem by including sk in the Apache config files, - but as usual, changes don't propagate to all of the mirrors fast. - -<toc-add-entry name="mirroring">Mirroring issues</toc-add-entry> - - <p>Sites are supposed to create the file mirror/timestamps/<host>. - Jay has made scripts that check the date in this file for each mirror so - we can know when a mirror is out of date, see mirror/timestamps/*.py. - - <p>We should reduce the number of web mirrors in Europe and increase the - number of mirrors on other, less connected continents. - - <p>Making all mirrors pushed (from www-master if possible) is also a goal. - - <p>Making sure whether each mirror has correct Apache configuration is a - pain, but there doesn't seem to be a way around that. Phil Hands suggested - that the "AddLanguage" stuff is put into a wgettable file and that we make - a Perl script that would automatically update people's Apache config - files. - - <P>All links into the archive should allow the user to select the download - site. The master mirror list could be used to keep the list of mirrors up - to date (maybe even using a script). See - <code>webwml/english/mirror/Mirrors.masterlist</code> and - <code>webwml/english/mirror/mirror_list.pl</code> files. - - <P><em>The mirror list is maintained by the people at mirrors@debian.org.</em> - -<toc-add-entry name="wrongurls">Wrong URLs</toc-add-entry> - - <p>Links to external pages have to be checked if they are still - correct. James Treacy has written a small Python script for this - purpose. Frank Lichtenheld is currently - maintaining the script, the (daily updated) results can be found at - <url "https://www-master.debian.org/build-logs/urlcheck/" />. - Broken links have to be removed. This is more of a permanent task.</p> - -<toc-add-entry name="misc">Miscellaneous requests</toc-add-entry> - - <p><strong>Deal with these as you wish.</strong></p> - - <P>If we had cgi.debian.org on a less used and faster host, we could have - more dynamic content on the web pages. - - <p>Javier suggested making DDP pages account for translations, - automatically. - - <p>Joey said: -<blockquote> -<p>I'd rather like to see a note on the security pages like:</p> - -<p> - Please note that we cannot guarantee that an intruder gets access to - our servers since they are connected to the internet. In such a - case an evil third party could potential modify uploads to - security.debian.org and modify web pages containing MD5 sums. We - are, however, trying our best to prohibit this. Please be advised - that there is no 100% security, only improvements to the current - situation. -</p> -</blockquote> - -<p>Joey should rephrase it probably. :)</p> - - <p>Should be added to /security/faq.</p> - - <p>"Vernon Balbert" <vbalbert@mediaone.net> suggested we make it - clear which kernel version is used in the latest version of Debian. - - <p>Matti Airas <mairas@iki.fi> suggested "doing language selection - with Apache mod_rewrite. Instead of having to explicitly go to - https://www.debian.org/intro/about.en.html (or some mirror), I could go to - https://www.debian.org/en/intro/about, which mod_rewrite then could replace - with the correct url." Note that this would require additional hacks in - order not to break relative links.</p> - - - <p>Chris Tillman suggested:</p> - -<blockquote> -<p>There is often confusion about which machines -Debian supports and which we don't, yet. There is a bewildering array of -machines, not to mention network cards, displays, mice, video cards, sound -cards, port types, and so forth which an individual system might -mix-and-match. Many of the Ports pages are out of date. - -<p>Debian supports a *lot* of systems. I think it would make sense to start -trying to list which ones, specifically. Also, it would be really nice to -know which ones aren't supported, both for new would-be users and for -developers as a todo list. - -<p>I think the easiest way to achieve this, would be to provide a web page -where people could enter in their system components, preferably chosen from -a list of known components with an 'other' capability. Then, they could also -enter a thumbs-up or thumbs-down, on Debian on that architecture. Also any -specific problems. - -<p>Then after submission of the user's hardware specs, the system can show a -(dated) list of previous user's experiences with those components. - -<p>We should also need to sprinkle pointers to this page into the install -documentation, FAQs, probably even put a link on the front Debian page. -</blockquote> - -<toc-add-entry name="bugs">Bug reports</toc-add-entry> - -<p><a href="https://bugs.debian.org/www.debian.org">The list of our bug -reports</a>. - -<hr> - -<p>Please submit anything else to -<a href="mailto:debian-www@lists.debian.org">our mailing list</a>. diff --git a/greek/devel/website/translating.wml b/greek/devel/website/translating.wml deleted file mode 100644 index 227e9c8caca..00000000000 --- a/greek/devel/website/translating.wml +++ /dev/null @@ -1,312 +0,0 @@ -#use wml::debian::template title="Translating Debian web pages" BARETITLE=true -#use wml::fmt::verbatim -#use wml::debian::translation-check translation="8627b3f6f68ecae195c89923923955f8e32ea092" maintainer="galaxico" - -<p>To make the job of the translators as easy as possible the pages are -generated a bit differently than many of you will be used to. The web pages -are actually generated using source that is marked up with -<a href="https://www.shlomifish.org/open-source/projects/website-meta-language/"><tt>wml</tt></a>. -There are separate directories for each language. -</p> - -<p>If you plan to start an entirely new translation of the Debian web site, -please see the <a href="#completenew">section on starting a new -translation</a>. -</p> - -<h2><a name="singlepages">Translating individual pages</a></h2> - -<p>We use WML to separate the specific content of a page from the elements -common to multiple pages. This means that one needs to edit certain WML -source files instead of HTML files. Please <a href="using_git">use Git</a> -to acquire the current sources. You'll need to check out at least two -directories: <tt>webwml/english/</tt> and <tt>webwml/<var><language></var>/</tt>.</p> - -<p>To translate a single page from English into your language, the original -.wml file needs to be translated and placed within the other language's -directory. The relative path and name need to be the same as in the English -directory in order for the links to continue to work.</p> - -<h3>Translation headers</h3> -<p>It is strongly -recommended that the translator adds an additional line to the headers -after the last <code>#use</code> statement to record the exact commit of -the original file that was translated, so that <a href="uptodate">updating is -easier</a>. The line looks like this: -<kbd>#use wml::debian::translation-check translation="<var><git_commit_hash></var>"</kbd> -Please note that if you generate the translatable file using <tt>copypage.pl</tt> -tool (which is highly recommended), the git commit hash will be generated -automatically. The usage of <tt>copypage.pl</tt> will be explained in the -following texts. -</p> - -<p>Some translation teams also use this line to mark the official -translator of each web page. Doing so, you will get automatic mails -when the pages you maintain are updated in English, and need your -attention to update the translation. For that, simply add your name as -maintainer at the end of the <code>#use</code> line to make it look -like this: -<kbd>#use wml::debian::translation-check translation="<var>git_commit_hash</var>" maintainer="<var>your name</var>"</kbd>. -The <tt>copypage.pl</tt> will do this automatically -if you set the <tt>DWWW_MAINT</tt> environment variable -or use the <tt>-m</tt> command-line switch. -</p> - -# I Removed cvs specific descriptions from here because of cvs to git transition. -# Help to update instruction if possible. -# -#<p>You also need to explain to the robot who you are, how often you -#want to get automatic mails and their content. For that, edit (or let -#your coordinator edit) the file -#webwml/<var>language</var>/international/<var>language</var>/translator.db.pl -#in the repository. The syntax should be quite understandable, and you can -##use the file of the French team as template if it does not exist for -#your language yet. The robot can send several kinds of information, and -#for each of them, you can choose the frequency at which it will be -#sent to you. The different kinds of information are: -#</p> - -#<ul> -# <li><b>summary</b>: a summary of which documents are outdated</li> -# <li><b>logs</b>: the "cvs log" between the translated and current versions</li> -# <li><b>diff</b>: "cvs diff"</li> -# <li><b>tdiff</b>: the script will try to find the part of the translated text modified by the English patch</li> -# <li><b>file</b>: add the current version of the file to translate</li> -#</ul> - -#<p>Then, for each of them, the value should be one of: 0 (never), 1 (monthly), 2 (weekly) or 3 (daily).</p> - -#<p>An example could be: -#</p> - -#<verbatim> -# 'Martin Quinson' => { -# email => 'martin.quinson@tuxfamily.org', -# summary => 3, -# logs => 3, -# diff => 3, -# tdiff => 0, -# file => 0 -# }, -#</verbatim> - -<p>The header of the web page can be easily produced by using the -<tt>copypage.pl</tt> script in the webwml root directory. The script -will copy the page to the right place, create directories and -makefiles if necessary, and add the required header automatically. -You will be warned if a page to be copied exists in the repository, whether -because the page was removed from the repository (due to it being -too out of date) or because somebody already committed a translation -and your local repository copy is not up to date. -</p> - -<p>In order to start using the <tt>copypage.pl</tt> you should first -configure the file <tt>language.conf</tt> in the <tt>webwml</tt> root directory, -which it will use to -determine the language you are translating to. That file needs up to -two lines: the first line gets the language name (like <tt>german</tt>) and -the second can optionally get the name of the maintaining translator. You can also -set the language through the use of the <tt>DWWW_LANG</tt> environment -variable and use the <tt>DWWW_MAINT</tt> environment variable to -put your name so that it will be added to the header of the wml -files generated as the maintainer for the translation. Or as a third possibility, -you can give language and (optionally) maintainer on the commandline via -<tt>-l german -m "Donald Duck"</tt> and not use the language.conf file at all. -There are other features -available in the script, just run it without any arguments to get the help. -</p> - -<p>After you have run e.g. <kbd>./copypage.pl <var>file</var>.wml</kbd>, -translate the original text within the file. Comments in files will indicate -if there are items that should not be translated; respect them. Don't do any -unnecessary changes to the formatting; if something needs to be fixed, it -should likely be done in the original file.</p> - -<h3>Page building and publishing</h3> - -<p>Since we use <a href="content_negotiation">content negotiation</a>, -HTML files are not named <tt><var>file</var>.html</tt> but -<tt><var>file</var>.<var><lang></var>.html</tt>, where <var><lang></var> -is the two letter code of the language, according to -<a href="https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes">ISO 639</a> -(e.g. <tt>fr</tt> for French).</p> - -<p>You can build HTML from WML by running -<kbd>make <var>file</var>.<var><lang></var>.html</kbd>. -If that works, check if the syntax is fully valid with -<kbd>weblint <var>file</var>.<var><lang></var>.html</kbd>.</p> - -<p>NOTE: The web pages are regularly rebuilt automatically on the -www-master server, based on the wml source in git. This process is for -the most part impervious to errors. However, if you commit a broken -file in the top level of your translation (e.g. the top-level -index.wml file), it will break the build process and stall all the -other updates to the web site. Please pay special attention to these -files.</p> - -<p>Once the page is good to go, you can commit it into Git. If you -have the permissions to do this yourself, please push the commits to -the <a href="https://salsa.debian.org/webmaster-team/webwml">webwml -git repository</a>; if not, send it to <a -href="translation_coordinators"> somebody with write access to the -repository</a>.</p> - -<h2><a name="completenew">Starting a new translation</a></h2> - -<p>If you would like to start translation of the Debian web pages into -a new language, send us e-mail (in English) at -<a href="mailto:webmaster@debian.org">webmaster@debian.org</a>. - -<p>First of all, clone our source tree, as described <a -href="using_git">on our Git introduction page</a>.</p> - -<p>After you have a git checkout, start by creating a new top level -directory for your translation, next to english/ and others. The name -of the translation directory must be in English and entirely lowercase -(e.g. "german", not "Deutsch").</p> - -<p>Copy the <tt>Make.lang</tt> and <tt>.wmlrc</tt> files from the english/ -directory to the new translation directory. These files are essential for -building your translation from WML files. They have been designed so that -after you copy them to the new language directory, you only have to change -these things:</p> - -<ol> - <li>The variable LANGUAGE must be changed in the file <tt>Make.lang</tt>. - - <li>The variables CUR_LANG, CUR_ISO_LANG and CHARSET must be changed in - the <tt>.wmlrc</tt> file. Add CUR_LOCALE to that, if you need it for - sorting. - - <li>Some languages may need extra processing to handle the charset. This - can be done using the --prolog and --epilog options to wml. Use the - WMLPROLOG and WMLEPILOG variables in <tt>Make.lang</tt> to do this. - - <li>The variable LANGUAGES must be changed in top-level - <tt>webwml/Makefile</tt> file so that your language will get built - along with the other ones, on www.debian.org. We would prefer if you - left this particular change up to the webmasters, because you may not - be aware that your translation is broken when checked out of VCS - afresh, which could break the building process of the rest of our web - site. -</ol> - -<p>After that is done, put the following line in a new file called -"Makefile" in that directory: - -<pre> -<protect>include $(subst webwml/<var>yourlanguagedir</var>,webwml/english,$(CURDIR))/Makefile</protect> -</pre> - -<p>(Replace <var>yourlanguagedir</var> with the name of your language's -directory, of course.)</p> - -<p>Now create a subdirectory inside your language's directory called "po", -and copy the same Makefile to that subdirectory (<kbd>cp ../Makefile .</kbd>). -</p> - -<p>In the po/ directory, run <kbd>make init-po</kbd> to generate the initial -set of *.po files.</p> - -<p>Now that you have the skeleton set up, you can start -adding your translations in our shared WML tags used in templates. -The first templates that you should translate are those that appear -on all of the web pages, like the header keywords, the entries in the -navigation bar, and the footer.</p> - -# The page on <a href="using_wml">using WML</a> has more information on this. - -<p>Start translating in the <code>po/templates.<var>xy</var>.po</code> file -(where <var>xy</var> is your language's two-letter code). For every -<code>msgid "<var>something</var>"</code> there is initially a -<code>msgstr ""</code> where you should fill in the translation of -<var>something</var> in the double quotes after <code>msgstr</code>.</p> - -<p>You don't have to translate all of the strings in all of the .po files, -just those that your currently translated pages actually need. To see if you -need to translate a string, see the comments in the .po file just above each -<code>msgid</code> statement. If the referenced file is in -<tt>english/template/debian</tt>, then you should most likely translate it. -If not, you can postpone it for later, when you actually translate the -relevant section of the web pages that require it.</p> - -<p>The point of po/ files is to make things easier for translators, so that -they (almost) never have to edit anything in the -<tt>english/template/debian</tt> directory itself. -If you find anything to be wrong with the way something -is set up in the template directory, please make sure that the problem is -fixed in a general manner (feel free to ask someone else to do it for you), -rather than commiting actual translations into the templates, which would -(usually) be a major problem.</p> - -<p>If you aren't sure if you did something properly, ask on the debian-www -mailing list before committing.</p> - -<p>Note: if you find you need to make any other changes, send mail to -debian-www saying what you changed and why, so the problem can be corrected. - -<p>After the template skeleton is done, you can start with translating the -front page and the other *.wml files. For a list of files that -should be translated first, check <a href="translation_hints">the hints -page</a>. Translate *.wml pages as described <a href="#singlepages">at -the top of this page</a>.</p> - -<h3>Reviving outdated translations</h3> - -<p>As described in <a href="uptodate">how to keep translations up to date</a>, -outdated translations of the website might be removed automatically when a -long period of time has gone by without an update.</p> - -<p>If you find that some files got removed sometime in the past and you would -like to checkout the file again for further editing, you may search through -the commit history using git's standard commands.</p> - -<p>For example, if the delete file is "deleted.wml", you may search the history -by running:</p> - -<verbatim> - git log --all --full-history -- <path/to/file/deleted.wml> -</verbatim> - -<p>You may find out the exact commit that removed the file you want, together -with the commit's hash string. To display the detail information about the -modification made to the file in this commit, you may -use <code>git show</code> subcommand:</p> - -<verbatim> - git show <COMMIT_HASH_STRING> -- <path/to/file/deleted.wml> -</verbatim> - -<p>If the commit is exactly the one that deleted the file, you may restore -the file to the workspace using <code>git checkout</code>:</p> - -<verbatim> - git checkout <COMMIT_HASH_STRING>^ -- <path/to/file/deleted.wml> -</verbatim> - -<p>Once you do this you have to, of course, update the document before -you check it in again. Or it might be otherwise removed.</p> - - -<h3>The rest of the story</h3> - -<p>The description above will probably be enough to get you started. -Afterwards, you will want to refer to the following documents which provide -more detailed explanations and additional useful information.</p> - -<ul> -<li>A number of <a href="examples">examples</a> are provided to give you - a clearer idea of how to get started. -<li>A number of common questions are answered and helpful hints provided in - the <a href="translation_hints">translation hints</a> page. -<li>We have mechanisms in place to aid in <a href="uptodate">keeping the - translations up to date</a>. -<li>To see the status of your translation and how it compares to others, - check the <a href="stats/">statistics</a>. -</ul> - -<P>We hope you find the work we've done will make translating -the pages as easy as possible. As has already been mentioned, if -you have any questions, you can ask them on the <a -href="mailto:debian-www@lists.debian.org">debian-www</a> mailing -list. diff --git a/greek/devel/website/translation_hints.wml b/greek/devel/website/translation_hints.wml deleted file mode 100644 index eb9edff683e..00000000000 --- a/greek/devel/website/translation_hints.wml +++ /dev/null @@ -1,174 +0,0 @@ -#use wml::debian::template title="Useful Translation Suggestions" -#include "$(ENGLISHDIR)/releases/info" -#use wml::debian::translation-check translation="d49333f670c2639f601fd741d3dd5f060de97e2b" maintainer="galaxico" - -<p>Please see the pages about <a href="working">working on the web pages</a> -which describe some general things to observe, not strictly limited to -translations. - -<h2>What to translate?</h2> - -<p>See the <a href="translating#completenew">instructions for starting a new -translation</a> for an introduction.</p> - -<p>Once you start translating pages, we recommend you start with pages -that users are most likely to visit. Here are some guidelines; also -note that the lists of pages in the <a href="stats/">translation -statistics</a> are ordered by popularity.</p> - -<dl> -<dt><strong>Most important:</strong></dt> - <dd> - <ul> - <li>the main directory: index.wml, contact.wml, donations.wml, - social_contract.wml, support.wml</li> - <li>the intro/ directory: about.wml, cn.wml, free.wml, why_debian.wml</li> - <li>the releases/ directory: index.wml</li> - <li>the releases/<current_release_name>/ directory: index.wml, - installmanual.wml, releasenotes.wml</li> - <li>the distrib/ directory: index.wml, packages.wml, netinst.wml, ftplist.wml</li> - <li>the mirror/ directory: list.wml</li> - <li>the CD/ directory: index.wml</li> - <li>the doc/ directory: index.wml</li> - <li>the MailingLists/ directory: index.wml</li> - <li>the security/ directory: index.wml</li> - </ul> - </dd> -<dt><strong>Standard:</strong></dt> - <dd>The remaining files in the aforementioned directories, and these: - <ul> - <li>Bugs/index.wml, Bugs/Reporting.wml</li> - <li>banners/index.wml</li> - <li>blends/index.wml</li> - <li>consultants/index.wml</li> - <li>doc/ddp.wml</li> - <li>events/index.wml</li> - <li>international/index.wml, and create a page (or directory) for your - language</li> - <li>logos/index.wml</li> - <li>mirror/index.wml</li> - <li>misc/index.wml</li> - <li>News/index.wml</li> - <li>News/weekly/index.wml</li> - <li>ports/index.wml</li> - <li>partners/index.wml</li> - </ul> - </dd> -<dt><strong>Optional:</strong></dt> - <dd>All the other files in the previously mentioned directories. - This includes the following directories which include subdirectories that - are modified frequently, so are harder to keep up to date: - <ul> - <li>MailingLists/desc/</li> - <li>News/</li> - <li>doc/books.wml</li> - <li>events/</li> - <li>security/</li> - </ul> - </dd> -<dt><strong>Least Important:</strong></dt> - <dd>Files in the devel/ and vote/ directories. Since they are mostly - for developers, and the primary language of developers is English, it - is only when you have a strong translation team should you attempt to - tackle these.</dd> -</dl> - -<p> -<strong>It is important that you only translate files that you have -the time to maintain. A few well maintained pages is much more useful -than a lot of out of date ones.</strong> - -<h2>How closely should translations follow the original?</h2> - -<p>There are times when you may want to make a change to the content when -you are translating. One example is on the support page; you will probably -want to include an example on subscribing to the language specific mailing -list, e.g. debian-user-french on the French version of the pages. - -<p>If you make more significant changes, please notify -<a href="mailto:debian-www@lists.debian.org">debian-www list</a> -as it is desired to keep the content as similar as possible -between the different versions. - -<p>The pages are meant to be useful. If you have information that -will help the users of your language, feel free to add it. You can use -international/<Language>.wml for all the stuff interesting to -Language-speaking visitors. - -<p>If you know of information that would be useful to all users, -bring it up on debian-www. - -<h2>How do translators know when files need to be updated?</h2> - -<P>There is a mechanism that translators can use to <a href="uptodate"> -keeping web site translations up-to-date</a>. - -<h2>How do we keep the gettext template translations up to date?</h2> - -<p>After the English files have been updated, run <kbd>make update-po</kbd> -in the <code>po/</code> subdirectory of your translation to update your .po -files with the originals. Watching the log messages on the -<a href="https://lists.debian.org/debian-www-cvs/">debian-www-cvs mailing -list</a> can be helpful to find out when this should be done; or you can -simply run it at regular intervals.</p> - -<p>Use the <kbd>make stats</kbd> command to see an overview of the changes. -Gettext will mark the tags whose value it had to guess with -"<code>#, fuzzy</code>", and newly introduced tags will simply have an empty -string after <code>msgstr</code>.</p> - -<h2>How do users know if a translated page is out of date?</h2> - -<P>The <code>translation-check</code> template which is used to -<a href="uptodate">keep translations up-to-date</a> will make a note in -translations which are outdated. - -<h2>Things to observe when translating</h2> - -<p>The following is a list of pages and directories that may require special -attention when translating: - -<dl> -<dt><tt>News/</tt> - <dd>You can translate as many or as few pieces of news as you wish. The - indices are created automatically from the titles of the items. If an - item has been translated, then the translated title will be used in the - index.</dd> - -<dt><tt>security/</tt> - <dd>This is set up similar to the News/ directory. There's one - difference, there are .data files that you should <em>not</em> translate.</dd> - -<dt><tt>CD/vendors/</tt> - <dd>Only the *.wml files in CD/vendors/ should be translated. - Translations for tags are added via gettext in the - po/vendors.<var>xy</var>.po file.</dd> - -<dt><tt>intro/organization.wml</tt> - <dd>Tags are translated via gettext in the - po/organization.<var>xy</var>.po file.</dd> - -<dt><tt>MailingLists/{un,}subscribe.wml</tt> - <dd>These two files are generated by the <tt>mklist</tt> script, so you - can't edit them directly. You can translate the files in the desc/ - subdirectory, they contain the descriptions of mailing lists. - Tags are translated via gettext in the po/mailinglists.<var>xy</var>.po - file. - </dd> - -<dt><tt>consultants/index.wml</tt> - <dd>Tags are translated via gettext in the po/consultants.<var>xy</var>.po - file.</dd> - -<dt><tt>releases/*/{installmanual,releasenotes}.wml</tt> - <dd>Translate everything but the Perl code (stuff enclosed in <: :>), - except for the <strong>second</strong> argument of permute_as_list.</dd> - -<dt><tt>ports/</tt> - <dd>Port pages may be volatile. You should only translate these if - you are willing to spend the time keeping them up to date.</dd> - -<dt><tt>devel/website/</tt> - <dd>This is for people editing or translating web pages, so it is - probably very low priority.</dd> -</dl> diff --git a/greek/devel/website/uptodate.wml b/greek/devel/website/uptodate.wml deleted file mode 100644 index f3eb75b01b5..00000000000 --- a/greek/devel/website/uptodate.wml +++ /dev/null @@ -1,103 +0,0 @@ -#use wml::debian::template title="Keeping web site translations up-to-date" -#use wml::debian::translation-check translation="8f2dd37edbf6287df4029e3f234798efbcce2862" maintainer="galaxico" - -<P>Since web pages aren't static, it is a good idea to keep track of which -version of the original a certain translation refers to, and to use this -information to check which pages have changed since the last translation. -This information should be embedded at the top of the document (though -below any other "use" headers) in this form: - -<pre> -\#use wml::debian::translation-check translation="git_commit_hash" -</pre> - -<p>where <var>git_commit_hash</var> is the git commit hash that refers -to the commit of the original (English) file that the translated file -was translated against. You can get the detail of that specific commit -using the <code>git show</code> tool: <code>git show -<git_commit_hash></code> . If you use the <kbd>copypage.pl</kbd> -script in the webwml directory, the <code>translation-check</code> -line is added automatically in the first version of your translated -page, pointing to the version of the original file that exists at that -point. </p> - -<p>Some translations may not get updated for quite some time, even -though the original language (English) has changed. Due to content -negotiation, the reader of the translated page may not be aware of -this and might miss important information, introduced in new versions -of the original. The <code>translation-check</code> template contains -code to check if your translation is outdated, and output an -appropriate message warning the user about it. </p> - -<P>There are more parameters that you can use on the -<code>translation-check</code> line: - -<dl> - <dt><code>original="<var>language</var>"</code> - <dd>where <var>language</var> is the name of the language you are translating - from, if not english. - The name must correspond to the top-level subdirectory in the VCS, and to - the name in <code>languages.wml</code> template. - - <dt><code>mindelta="<var>number</var>"</code> - <dd>which defines the maximum difference in git revisions before the - translation is considered to be <strong>aged</strong>. The default - value is <var>1</var>. For less important pages, set it to - <var>2</var>, meaning that two changes need to be made before the - translation will be considered aged. - - <dt><code>maxdelta="<var>number</var>"</code> - <dd>which defines the maximum differenc in git revisions before the - translation is considered to be <strong>outdated</strong>. The - default value is <var>5</var>. For very important pages, set it to a - smaller number. A value of <var>1</var> means that every change will - cause the translation to be marked as outdated. -</dl> - -<p>Tracking the age of translations also enables us to have <a -href="stats/">translation statistics</a>, a report of outdated -translations (together with helpful links to the differences between -files), along with a list of pages that haven't been translated at -all. This is intended to help translators and to attract new people to -help. </p> - -<p> -To avoid presenting our users with information that is too outdated, -translations that have not been updated within six months from when the -original page was changed will be purged automatically. -Please see the -<a href="https://www.debian.org/devel/website/stats/">list of outdated -translations</a> to find which pages are in danger of being purged. -</p> - -<P>Additionally, the script <kbd>check_trans.pl</kbd> is available in the -webwml/ directory, which will show you a report on pages needing updates: - -<pre> -check_trans.pl <var>language</var> -</pre> - -<P>where <var>language</var> is the directory name that contains your -translation, e.g. "swedish". - -<P>Pages that lack translation will be shown as -"<code>Missing <var>filename</var></code>", and pages that are not up to -date with the original will be shown as -"<code>NeedToUpdate <var>filename</var> to version <var>XXXXXXX</var></code>". - -<P>If you want to see what the exact changes are, you can get the -differences by adding <kbd>-d</kbd> command line option to the above -command.</p> - -<P>If you want to ignore warnings about missing translations (for -instance for old news items), you can create a file called -<code>.transignore</code> in the directory where you want to suppress -the warnings, listing each file that you are not going to translate, -with one name per line. - -<p> -A similar script for keeping track of the translations of the mailing lists -descriptions is also available. -Please read the comments in the <code>check_desc_trans.pl</code> script for -documentation. -</p> diff --git a/greek/devel/website/using_git.wml b/greek/devel/website/using_git.wml deleted file mode 100644 index aaa809a9316..00000000000 --- a/greek/devel/website/using_git.wml +++ /dev/null @@ -1,311 +0,0 @@ -#use wml::debian::template title="Using git to manipulate website source code" -#use wml::debian::translation-check translation="74a4415fa07f5810685f1d0568bf4b695cc931b3" maintainer="galaxico" - -<h2>Introduction</h2> - -<p>Git is a <a href="https://en.wikipedia.org/wiki/Version_control">version -control system</a> that helps to manage having multiple people work on -the same material simultaneously. Every user can hold a local copy of a main -repository. The local copies can be on the same machine, or across the world. -Users can then modify the local copy as they wish and when the modified -material is ready, commit the changes and push them back to the main -repository.</p> - -<p>Git will not let you push a commit directly if the remote repository has -any newer commits (modifications) than your local copy on the same branch. -In such case where conflict takes place, please fetch and update your local -copy first and <code>rebase</code> your new modifications on top of the latest -commit as needed. -</p> - -<h3><a name="write-access">Git repository write access</a></h3> - -<p> -The whole Debian website source code is managed under Git. It is located -at <url https://salsa.debian.org/webmaster-team/webwml/>. By default, -guests are not allowed to push commits onto the source code repository. -You will need some kind of permission to gain write access to the -repository. -</p> - -<h4><a name="write-access-unlimited">Unlimited write access</a></h4> -<p> -If you need unlimited write access to the repository (e.g., You are about to -become a frequent contributor), please consider requesting write access via -the <url https://salsa.debian.org/webmaster-team/webwml/> web interface after -logging in to Debian's Salsa platform. -</p> - -<p> -If you are new to Debian's website development and have no previous experience, -please also send a mail to <a href="mailto:debian-www@lists.debian.org"> -debian-www@lists.debian.org</a> with your self introduction before requesting -unlimited write access. Please provide with something useful in your -introduction, like which language or which part of the website you plan to -work on, and who would vouch for you. -</p> - -<h4><a name="write-access-via-merge-request">Write into repository via Merge Requests</a></h4> -<p> -If you do not intend to get unlimited write access to the repository or -is unable to do so, you can always submit a Merge Request and let other -developers to review and accept your work. Please submit Merge Requests -using the standard procedure as provided by the Salsa GitLab platform via -its web interface (read -<a href="https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html">Project forking workflow</a> -and -<a href="https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#when-you-work-in-a-fork">When you work in a fork</a> -for details). -</p> - -<p> -The Merge Requests are not monitored by all website developers thus it may -not always be processed in time. If you are not sure whether your contribution -would be accepted, please send a email to the -<a href="https://lists.debian.org/debian-www/">debian-www</a> -mailing list and request for a review. -</p> - -<h2><a name="work-on-repository">Working on the repository</a></h2> - -<h3><a name="get-local-repo-copy">Get a local copy of the repository</a></h3> - -<p>First, you need to install git to work with the repository. Next, -configure your user and e-mail details on your computer (please refer -to general git documentation to learn how to do this). Then, you can -clone the repository (in other words, make a local copy of it) -in one of two ways.</p> - -<p>The recommended way to work on webwml is to first register an -account on salsa.debian.org and enable git SSH access by uploading an -SSH public key into your salsa account. See the <a -href="https://salsa.debian.org/help/user/ssh.md">salsa help -pages</a> for more details on how to do that. Then you can clone the -webwml repository using the following command:</p> - -<pre> - git clone git@salsa.debian.org:webmaster-team/webwml.git -</pre> - -<p>If you don't have a salsa account, an alternative method is to -clone the repository using the HTTPS protocol:</p> - -<pre> - git clone https://salsa.debian.org/webmaster-team/webwml.git -</pre> - -<p>This will give you the same repository copy locally, but you will -not be able to directly push changes back directly this way.</p> - -<p>Cloning the whole webwml repository will require downloading about -500MB of data, thus it may be difficult for those with slow or -unstable Internet connections. You may try shallow cloning with -a minimum depth first for a smaller initial download:</p> - -<pre> - git clone git@salsa.debian.org:webmaster-team/webwml.git --depth 1 -</pre> - -<p>After obtaining a usable (shallow) repository, you can deepen the -local shallow copy and eventually convert it to a full local -repository: </p> - -<pre> - git fetch --deepen=1000 # deepen the repo for another 1000 commits - git fetch --unshallow # fetch all missing commits, convert the repo to a complete one -</pre> - -<h4><a name="partial-content-checkout">Partial content checkout</a></h4> - -<p>You can create a checkout for only a subset of the pages like this:</p> - -<pre> - $ git clone --no-checkout git@salsa.debian.org:webmaster-team/webwml.git - $ cd webwml - $ git config core.sparseCheckout true - In webwml: Create the file .git/info/sparse-checkout with content like this - (if you only want the base files, English, Catalan and Spanish translations): - /* - !/[a-z]*/ - /english/ - /catalan/ - /spanish/ - Then: - $ git checkout -- -</pre> - -<h3><a name="submit-changes">Submitting local changes</a></h3> - -<h4><a name="keep-local-repo-up-to-date">Keep your local repo up-to-date</a></h4> - -<p>Every few days (and definitely before starting some editing work!) -you should do a</p> - -<pre> - git pull -</pre> - -<p>to retrieve any files from the repository which have changed.</p> - -<p> -It is strongly recommended to keep your local git working directory clean -before performing "git pull" and following editing work. If you have -uncommitted changes or local commits that are not present in the remote -repository on the current branch, doing "git pull" will automatically create -merge commits or even fail due to conflicts. Please consider keeping your -unfinished work in another branch or using commands like "git stash". -</p> - -<p>Note: git is a distributed (not centralised) version control -system. This means that when you commit changes they will only be -stored in your local repository. To share them with others, you will -also need to push your changes to the central repository on salsa.</p> - -<h4><a name="example-edit-english-file">Example on editing English files</a></h4> - -<p> -An example on how to edit English files within the website source code -repository is provided here. After obtaining a local copy of the repo -using "git clone" and before starting the editing work, run the following -command: -</p> - -<pre> - $ git pull -</pre> - -<p>Now make changes to files. When you are done, commit your changes -to your local repository using:</p> - -<pre> - $ git add path/to/file(s) - $ git commit -m "Your commit message" -</pre> - -<p>If you have unlimited write access to the remote webwml repository, you -may now push your changes directly onto the Salsa repo:</p> - -<pre> - $ git push -</pre> - -<p>If you do not have direct write access to the webwml repository, please -consider submitting your changes using the Merge Request function as provided -by Salsa GitLab platform or asking other developers for help. -</p> - -<p>That's a very basic summary of how to use git to manipulate the -Debian website's source code. For more information on git, please read -git's documentation.</p> - -<h4><a name="closing-debian-bug-in-git-commits">Closing Debian bugs in git commits</a></h4> - -<p> -If you include <code>Closes: #</code><var>nnnnnn</var> in your commit log -entry, then bug number <code>#</code><var>nnnnnn</var> will be closed -automatically when you push your changes. The precise form of this is the same as -<a href="$(DOC)/debian-policy/ch-source.html#id24">in Debian policy</a>.</p> - -<h4><a name="links-using-http-https">Linking using HTTP/HTTPS</a></h4> - -<p>Many Debian websites support SSL/TLS, so please use HTTPS links where -possible and sensible. <strong>However</strong>, some -Debian/DebConf/SPI/etc websites either don't have have HTTPS support -or only use the SPI CA (and not an SSL CA trusted by all browsers). To -avoid causing error messages for non-Debian users, please do not link -to such sites using HTTPS.</p> - -<p>The git repository will reject commits containing plain HTTP links -for Debian websites that support HTTPS or containing HTTPS links for -the Debian/DebConf/SPI websites that are known to either not support -HTTPS or use certificates signed only by SPI.</p> - -<h3><a name="translation-work">Working on translations</a></h3> - -<p>Translations should always be kept to be up-to-date with its -corresponding English file. The "translation-check" header in translation -files is used to track which version of English file the current -translation was based on. If you change translated files, you need to update the -translation-check header to match the git commit hash of the -corresponding change in the English file. You can find that hash -with</p> - -<pre> -$ git log path/to/english/file -</pre> - -<p>If you do a new translation of a file, please use the <q>copypage.pl</q> script -and it will create a template for your language, including the correct -translation header.</p> - -<h4><a name="translation-smart-change">Translation changes with smart_change.pl</a></h4> - -<p><code>smart_change.pl</code> is a script designed to make it easier -to update original files and their translations together. There are -two ways to use it, depending on what changes you are making.</p> - -<p>To use <code>smart_change</code> to just update the translation-check -headers when you're working on files manually:</p> - -<ol> - <li>Make the changes to the original file(s), and commit</li> - <li>Update translations</li> - <li>Run smart_change.pl - it will pick up the changes and update - headers in the translated files</li> - <li>Review the changes (e.g. with "git diff")</li> - <li>Commit the translation changes</li> -</ol> - -<p>Or, if you're using smart_change with a regular expression to make -multiple changes across files in one pass:</p> - -<ol> - <li>Run <code>smart_change.pl -s s/FOO/BAR/ origfile1 origfile2 ...</code></li> - <li>Review the changes (e.g. with <code>git diff</code>) - <li>Commit the original file(s)</li> - <li>Run <code>smart_change.pl origfile1 origfile2</code> - (i.e. <strong>without the regexp</strong> this time);it will now - just update headers in the translated files</li> - <li>Finally, commit the translation changes</li> -</ol> - -<p>This is more involved than the previous one (needing two commits), but -unavoidable due to the way git commit hashes work.</p> - -<h2><a name="notifications">Getting notifications</a></h2> - -<h3><a name="commit-notifications">Receiving commit notifications</a></h3> - -<p>We have configured the webwml project in Salsa so that commits are -shown in the IRC channel #debian-www.</p> - -<p>If you want to receive notifications via e-mail when there are -commits in the webwml repo, please subscribe to the <q>www.debian.org</q> -pseudopackage via tracker.debian.org and activate the <q>vcs</q> keyword -there, following these steps (only once):</p> - -<ul> - <li>Open a web browser and go to <url https://tracker.debian.org/pkg/www.debian.org></li> - <li>Subscribe to the <q>www.debian.org</q> pseudopackage. (You can authenticate - via SSO or register an email and password, if you were not using - tracker.debian.org already for other purposes).</li> - <li>Go to <url https://tracker.debian.org/accounts/subscriptions/>, then to <q>modify - keywords</q>, check <q>vcs</q> (if it's not checked) and save.</li> - <li>From now on you will get e-mails when somebody commits to the - webwml repo. We will add the other webmaster-team repositories soon.</li> -</ul> - -<h3><a name="merge-request-notifications">Receiving Merge Request notifications</a></h3> - -<p> -If you wish to receive notification emails whenever there are new Merge -Requests submitted on the webwml repository web interface on Salsa GitLab -platform, you may configure your notification settings for the webwml -repository on the web interface, following these steps: -</p> - -<ul> - <li>Log in to your Salsa account and go to the project page;</li> - <li>Click the bell icon on the top of the project homepage;</li> - <li>Select the notification level you prefer.</li> -</ul> diff --git a/greek/devel/website/using_wml.wml b/greek/devel/website/using_wml.wml deleted file mode 100644 index 469285f4338..00000000000 --- a/greek/devel/website/using_wml.wml +++ /dev/null @@ -1,68 +0,0 @@ -#use wml::debian::template title="Using WML" -#use wml::debian::translation-check translation="24a8bbc5bf2fd2fbe025f0baa536bf1126f83723" maintainer="galaxico" - -<p>WML stands for web site meta language. This means that WML takes input -.wml files, processes whatever is inside them (it can be anything from basic -HTML to Perl code!), and outputs whatever you want it to output, for example -.html or .php.</p> - -<p>The documentation for WML is not easy to learn from. It is actually quite -complete, but until you begin to understand how it works (and it is quite -powerful) it is easiest to learn from examples. You may find template files -used for the Debian site useful. They can be found in -<code><a href="https://salsa.debian.org/webmaster-team/webwml/tree/master/english/template/debian">\ -webwml/english/template/debian/</a></code>.</p> - -<p>This assumes that you have WML installed on your machine. -WML is available as a -<a href="https://packages.debian.org/wml">Debian package</a>. - - -<h2>Editing WML sources</h2> - -<p>One thing all .wml files will have is one or more opening <code>#use</code> -lines. You must not change or translate their syntax, only the quoted -strings such as those after <code>title=</code>, which would change the -<title> element in the output files.</p> - -<p>Other than the header lines, most of our .wml pages contain simple HTML. -If you encounter tags such as <define-tag> or <: ... :>, be -careful, because those delimit code that's processed by one of WML's special -passes. See below for more information.</p> - - -<h2>Building Debian web pages</h2> - -<p>Simply type <kbd>make</kbd> in webwml/<lang>. We have set up -makefiles that call <kbd>wml</kbd> with all the right arguments.</p> - -<p>If you do a <kbd>make install</kbd> then the HTML files will be built and -placed in the directory <kbd>../../www/</kbd>.</p> - - -<h2>Extra WML features we use</h2> - -<p>One of the features of WML that we make extensive use of is the use of Perl. -Remember, these are not dynamic pages. Perl is used at the time the HTML -pages are generated to do, well, whatever you like. Two good examples of how -we are using Perl in the pages is to create the list of most recent news items for -the main page and to generate the links to translations at the end of the page. - -# TODO: add the basic stuff from webwml/english/po/README here - -<p>To rebuild the templates of our web site, wml version >= 2.0.6 is -needed. To rebuild the gettext templates for non-English translations, -mp4h >= 1.3.0 is necessary.</p> - - -<h2>Specific issues with WML</h2> - -<p>Multi-byte languages may need special pre- or post-processing of the .wml -files in order to handle the character set properly. This can be done by -changing the variables <kbd>WMLPROLOG</kbd> and <kbd>WMLEPILOG</kbd> in -<kbd>webwml/<lang>/Make.lang</kbd> appropriately. Depending on how -your <kbd>WMLEPILOG</kbd> program works, you may need to change the value of -<kbd>WMLOUTFILE</kbd>. -<br> -See the Japanese or Chinese translations for an example. -</p> diff --git a/greek/devel/website/working.wml b/greek/devel/website/working.wml deleted file mode 100644 index 3375273338b..00000000000 --- a/greek/devel/website/working.wml +++ /dev/null @@ -1,253 +0,0 @@ -#use wml::debian::template title="How to work on the Debian web pages" BARETITLE=true -#use wml::debian::toc -#use wml::debian::translation-check translation="b5c35a479efa1910b978df5114fd87e4142e3892" maintainer="galaxico" - -<toc-display/> - - - -<toc-add-entry name="general">General information</toc-add-entry> - -<h3>Resource requirements</h3> - -<p>If you want to work on our web site, please be prepared to store at least -740 MB of data on your disk. This reflects the current size of the source -archive. If you (accidentally) rebuild all of the pages, you will need at -least three times as much space.</p> - -<h3><q>What are these lines beginning with `#'?</q></h3> - -<p>In WML, a line beginning with a `#' is a comment. These are preferred to -normal HTML comments as they don't show up on the final page.</p> - -<p>Please read the page on <a href="using_wml">using WML</a> for more -information on WML.</p> - -<toc-add-entry name="etiquette">Etiquette for editors</toc-add-entry> - -<h3><q>Can I modify this page?</q></h3> - -<p>That depends. If you see a small mistake, like a typo, just fix it.</p> - -<p>If you notice that some bit of information is missing, feel free to fix -it, too.</p> - -<p>If you feel that something is awful and needs to be rewritten, bring it -up on debian-www so it can be discussed. We'll probably agree with you.</p> - -<p>If you notice there's a problem in a template (i.e. a file in -webwml/english/template/debian directory), please think about the change -before committing it, because changes to templates often cause large portions -of the site to get rebuilt.</p> - -<h3>When adding new directories, also add the Makefile!</h3> - -<p>Some care should be taken when adding a new directory to git. If the -current directory is listed in ../Makefile then you <b>must</b> create a -Makefile in it — otherwise <tt>make</tt> will give an error message.</p> - -<h3>Use clear and simple English</h3> - -<p>Since the Debian web pages are read by non-native speakers of English -and are translated into other languages, it is best to write in clear and -simple English and avoid the use of slang, emoticons and obscure idioms. -</p> - -<p>If you do use any of this, add a comment to the file explaining the -meaning.</p> - -<p> -If any doubt, or in order to proofread your proposal, please contact the <a -href="mailto:debian-l10n-english@lists.debian.org">English localization team</a>. -</p> - -<h3>Look for READMEs</h3> - -<p>Some of the directories contain a README to help you understand -how that directory is organized. These should provide any special -information needed when working in that area.</p> - -<h3>Separate the changes in content from the changes in formatting</h3> - -<p>Always make separate patches or commits for content changes and for -changes in formatting. When they are combined, it's much harder for -translators to find the differences. If you run <kbd>git diff -u</kbd> with -such mixed changes, you can see the mess for yourself.</p> - -<p>In general, avoid random formatting changes. Making older parts of pages -XHTML/XML-compliant shouldn't be done in the same commit with other changes. -(New stuff can and should be done properly from the start, of course.)</p> - - -<h3>Update translations, too, if possible</h3> - -<p>Some changes are independent of the language used in a WML file, like -changes to URLs or embedded Perl code. Fixing typos also falls in the same -category, because translators have usually ignored them while translating. -With such language-independent changes, you can do the same change in -all the translated files without actually knowing the other languages, -and safely increase the version in the translation-check headers.</p> - -<p>It's not terribly hard for translators to do the same work themselves, -and it can be inconvenient for English-speaking editors to have a full -checkout in which to operate. However, we still encourage people to do this -in order to avoid bothering two dozen people for something that can be done -quickly by a single person.</p> - -<p>In addition, to make such changes easier to apply, you can use the -<a href="using_git#translation-smart-change"><code>smart_change.pl</code></a> -script from the top-level directory in the webwml git module.</p> - -<toc-add-entry name="links">Links</toc-add-entry> - -<h3><q>This link doesn't look right. Should I change it?</q></h3> - -<p>Because of the way the web servers are set up (using -<a href="content_negotiation">content negotiation</a>), -you should not have to change any of the internal links. -In fact we suggest you don't. Write to debian-www -if you feel a link is incorrect before changing it.</p> - -<h3>Fixing links</h3> - -<p>If you notice a link to an external web site results in a redirection -(301, 302, a <meta> redirect, or a page saying <q>This page has moved.</q>) -please tell debian-www about it.</p> - -<p>If you find a broken link (404, 403, or a page that's not what the link -says it is), please fix it and tell debian-www about it so translators are -aware. Even better, fix the link in all the other translations, and update -translation-check headers if possible.</p> - -<toc-add-entry name="special">Separation of text from data</toc-add-entry> - -<h3><q>What are these foo.def and foo.data files?</q></h3> - -<p>To make it easier to keep the translations up to date, we separate the -generic parts (data) from the textual parts (text) of some pages. The -translators only need to copy and translate the textual parts of those, the -generic parts will be added automatically.</p> - -<p>An example may help in understanding this. It takes several files to -generate the page of vendor listings in <code>CD/vendors</code>:</p> - -<dl> - <dt><code>index.wml</code>:</dt> - <dd>The text at the top of the vendors page is in this file. - A translated copy of this should be placed in each language directory.</dd> - <dt><code>vendors.CD.def</code>:</dt> - <dd>This contains all the pieces of text which are needed for each - vendor entry. Translations are added via - <code><<var>language</var>>/po/vendors.<var>xy</var>.po</code>.</dd> - <dt><code>vendors.CD</code>:</dt> - <dd>This file contains the actual vendor entries which are independent - on the language, so a translator doesn't need to touch this file.</dd> -</dl> - -<p>When one of the people behind <email "cdvendors@debian.org"> adds a -new vendor, they add it to <code>debiancd.db</code>, convert it into WML -format as <code>vendors.CD</code> (using <code>getvendors.pl</code>), -and then let WML and the makefiles do their magic. All the translations -get rebuilt using the existing translated text but with the new vendor -data. (An updated translation for free!)</p> - -<toc-add-entry name="newpage">Adding a new page</toc-add-entry> - -<p>Adding new pages to Debian is quite easy. All the work of getting the -header and footer right are done using WML. All you need to do is to include -a line such as the following at the top of the new file:</p> - -<pre><protect> -#use wml::debian::template title="TITLE OF PAGE" -</protect></pre> - -<p>followed by the body. All pages should use the -<code>wml::debian::template</code> template file unless they are using -a special one created just for that section, e.g. the News or security items.</p> - -<p>The templates we have allow you to define certain variables which will -affect the pages created. This should avoid having to create different -templates for every situation and allow improvements to be easier to -implement. The variables currently available and their purpose are:</p> - -<dl> -<dt>BARETITLE="true"</dt> - <dd>Removes the "Debian --" part that is usually prepended - to all the <title> tags.</dd> -<dt>NOHEADER="true"</dt> - <dd>Removes the initial header from the page. A custom header - can, of course, be included in the body.</dd> -<dt>NOMIRRORS="true"</dt> - <dd>Removes the mirror dropdown list from the page. It is generally - not recommended to be used, except for a handful of pages.</dd> -<dt>NOHOMELINK="true"</dt> - <dd>Removes the link back to the main Debian page, which is normally - added to the bottom of the page.</dd> -<dt>NOLANGUAGES="true"</dt> - <dd>Removes the links to versions in other languages, which are - normally added to the bottom of the page.</dd> -<dt>GEN_TIME="true"</dt> - <dd>Sets the date on the resulting files to the timestamp of the - generated files, instead of the timestamp of the source file.</dd> -<dt>NOCOPYRIGHT="true"</dt> - <dd>Removes the copyright notice at the bottom of the page.</dd> -</dl> - -<p>Note that you can use any string as the value of these variables, -<q>true</q>, <q>yes</q>, <q>foo</q>, it doesn't matter.</p> - -<p>An example of the use of this is in the ports pages which have -their own headers. <code>ports/arm/index.wml</code> uses:</p> - -<pre><protect> -#use wml::debian::template title="ARM Port" NOHEADER="yes" -</protect></pre> - -<p>If you want to do something that can't be done using the existing -templates, first consider extending one of them. If it isn't -possible to extend one in a backward compatible way, try to make -the new template a superset of an existing one so the pages can -be converted to it at the next major upgrade (hopefully never more -than every 6 months).</p> - -<p>If you are creating a page that is generated by a script or has -little prose, consider using the <gettext> tags to ease -the task of keeping translations up to date.</p> - -# think of a good example for <gettext> in new pages - -<toc-add-entry name="inclusion">Including other files</toc-add-entry> - -<p>If you want to separate some parts of your page into a distinct file - (which is then included by your main file) use - the extension <code>.src</code> if your file contains content which should - be translated because then your included file is tracked for changes as - any ordinary <code>.wml</code> file. If you use any other extension, like - <code>.inc</code>, translators will not notice your updates and different - languages might ship different content.</p> - -<toc-add-entry name="newdir">Adding a new directory</toc-add-entry> - -<p>Note: do <strong>not</strong> create a directory with the name -<code>install</code>. This confuses make and the pages in that directory -will not be updated automatically.</p> - -<p>Below is an annotated example of adding a new directory to the web site. -</p> -<pre> - mkdir foo - git add foo - cd foo - cp ../intro/Makefile . - git add Makefile -</pre> - -<p>Edit the Makefile in the parent directory and add the directory you just -created to the <code>SUBS</code> variable. This will add the directory to -the build for when make is run.</p> - -<p>Finally, commit all the changes just made to the repository with -</p> -<pre> - git commit Makefile foo -</pre> diff --git a/greek/devel/wnpp/Makefile b/greek/devel/wnpp/Makefile deleted file mode 100644 index c26323c0c92..00000000000 --- a/greek/devel/wnpp/Makefile +++ /dev/null @@ -1 +0,0 @@ -include $(subst webwml/greek,webwml/english,$(CURDIR))/Makefile diff --git a/greek/devel/wnpp/being_adopted.wml b/greek/devel/wnpp/being_adopted.wml deleted file mode 100644 index 0cc0dd3bca7..00000000000 --- a/greek/devel/wnpp/being_adopted.wml +++ /dev/null @@ -1,18 +0,0 @@ -#use wml::debian::template title="Packages currently being adopted" GEN_TIME="true" -#use wml::debian::translation-check translation="9c91dafe36ecc3ea323c52c9c21d02f91dca4751" maintainer="galaxico" - -#include "$(ENGLISHDIR)/devel/wnpp/wnpp.data" - -<p> -This list is also available organized -<a href="being_adopted_byage">by age</a> or -<a href="being_adopted_byactivity">by activity</a>. -</p> - -<being_adopted /> - -<p> -This list is also available organized -<a href="being_adopted_byage">by age</a> or -<a href="being_adopted_byactivity">by activity</a>. -</p> diff --git a/greek/devel/wnpp/being_adopted_byactivity.wml b/greek/devel/wnpp/being_adopted_byactivity.wml deleted file mode 100644 index 5fab1cd913e..00000000000 --- a/greek/devel/wnpp/being_adopted_byactivity.wml +++ /dev/null @@ -1,18 +0,0 @@ -#use wml::debian::template title="Packages currently being adopted, organized by activity" GEN_TIME="true" -#use wml::debian::translation-check translation="9c91dafe36ecc3ea323c52c9c21d02f91dca4751" maintainer="galaxico" - -#include "$(ENGLISHDIR)/devel/wnpp/wnpp.data" - -<p> -This list is also available organized -<a href="being_adopted">by package name</a> or -<a href="being_adopted_byage">by age</a>. -</p> - -<being_adopted_byactivity /> - -<p> -This list is also available organized -<a href="being_adopted">by package name</a> or -<a href="being_adopted_byage">by age</a>. -</p> diff --git a/greek/devel/wnpp/being_adopted_byage.wml b/greek/devel/wnpp/being_adopted_byage.wml deleted file mode 100644 index 46c24790ed6..00000000000 --- a/greek/devel/wnpp/being_adopted_byage.wml +++ /dev/null @@ -1,18 +0,0 @@ -#use wml::debian::template title="Packages currently being adopted, organized by age" GEN_TIME="true" -#use wml::debian::translation-check translation="9c91dafe36ecc3ea323c52c9c21d02f91dca4751" maintainer="galaxico" - -#include "$(ENGLISHDIR)/devel/wnpp/wnpp.data" - -<p> -This list is also available organized -<a href="being_adopted">by package name</a> or -<a href="being_adopted_byactivity">by activity</a>. -</p> - -<being_adopted_byage /> - -<p> -This list is also available organized -<a href="being_adopted">by package name</a> or -<a href="being_adopted_byactivity">by activity</a>. -</p> diff --git a/greek/devel/wnpp/being_packaged.wml b/greek/devel/wnpp/being_packaged.wml deleted file mode 100644 index 045f950378d..00000000000 --- a/greek/devel/wnpp/being_packaged.wml +++ /dev/null @@ -1,18 +0,0 @@ -#use wml::debian::template title="Packages being worked on" GEN_TIME="true" -#use wml::debian::translation-check translation="9c91dafe36ecc3ea323c52c9c21d02f91dca4751" maintainer="galaxico" - -#include "$(ENGLISHDIR)/devel/wnpp/wnpp.data" - -<p> -This list is also available organized -<a href="being_packaged_byage">by age</a> or -<a href="being_packaged_byactivity">by activity</a>. -</p> - -<being_packaged /> - -<p> -This list is also available organized -<a href="being_packaged_byage">by age</a> or -<a href="being_packaged_byactivity">by activity</a>. -</p> diff --git a/greek/devel/wnpp/being_packaged_byactivity.wml b/greek/devel/wnpp/being_packaged_byactivity.wml deleted file mode 100644 index 9b0a1d58531..00000000000 --- a/greek/devel/wnpp/being_packaged_byactivity.wml +++ /dev/null @@ -1,18 +0,0 @@ -#use wml::debian::template title="Packages being worked on, organized by activity" GEN_TIME="true" -#use wml::debian::translation-check translation="9c91dafe36ecc3ea323c52c9c21d02f91dca4751" maintainer="galaxico" - -#include "$(ENGLISHDIR)/devel/wnpp/wnpp.data" - -<p> -This list is also available organized -<a href="being_packaged">by package name</a> or -<a href="being_packaged_byage">by age</a>. -</p> - -<being_packaged_byactivity /> - -<p> -This list is also available organized -<a href="being_packaged">by package name</a> or -<a href="being_packaged_byage">by age</a>. -</p> diff --git a/greek/devel/wnpp/being_packaged_byage.wml b/greek/devel/wnpp/being_packaged_byage.wml deleted file mode 100644 index 5eb4c22c5d2..00000000000 --- a/greek/devel/wnpp/being_packaged_byage.wml +++ /dev/null @@ -1,18 +0,0 @@ -#use wml::debian::template title="Packages being worked on, organized by age" GEN_TIME="true" -#use wml::debian::translation-check translation="9c91dafe36ecc3ea323c52c9c21d02f91dca4751" maintainer="galaxico" - -#include "$(ENGLISHDIR)/devel/wnpp/wnpp.data" - -<p> -This list is also available organized -<a href="being_packaged">by package name</a> or -<a href="being_packaged_byactivity">by activity</a>. -</p> - -<being_packaged_byage /> - -<p> -This list is also available organized -<a href="being_packaged">by package name</a> or -<a href="being_packaged_byactivity">by activity</a>. -</p> diff --git a/greek/devel/wnpp/help_requested.wml b/greek/devel/wnpp/help_requested.wml deleted file mode 100644 index 3cb8788c953..00000000000 --- a/greek/devel/wnpp/help_requested.wml +++ /dev/null @@ -1,18 +0,0 @@ -#use wml::debian::template title="Packages for which help was requested" GEN_TIME="true" -#use wml::debian::translation-check translation="2e1044712299f75aac55782c35ffe2ebce9eb3e5" maintainer="galaxico" - -#include "$(ENGLISHDIR)/devel/wnpp/wnpp.data" - -<p> -This list is also available organized -<a href="help_requested_byage">by age</a> or -<a href="help_requested_bypop">by popularity</a>. -</p> - -<help_req /> - -<p> -This list is also available organized -<a href="help_requested_byage">by age</a> or -<a href="help_requested_bypop">by popularity</a>. -</p> diff --git a/greek/devel/wnpp/help_requested_byage.wml b/greek/devel/wnpp/help_requested_byage.wml deleted file mode 100644 index 17a800b8661..00000000000 --- a/greek/devel/wnpp/help_requested_byage.wml +++ /dev/null @@ -1,18 +0,0 @@ -#use wml::debian::template title="Packages for which help was requested, organized by age" GEN_TIME="true" -#use wml::debian::translation-check translation="2e1044712299f75aac55782c35ffe2ebce9eb3e5" maintainer="galaxico" - -#include "$(ENGLISHDIR)/devel/wnpp/wnpp.data" - -<p> -This list is also available organized -<a href="help_requested">by package name</a> or -<a href="help_requested_bypop">by popularity</a>. -</p> - -<help_req_byage /> - -<p> -This list is also available organized -<a href="help_requested">by package name</a> or -<a href="help_requested_bypop">by popularity</a>. -</p> diff --git a/greek/devel/wnpp/help_requested_bypop.wml b/greek/devel/wnpp/help_requested_bypop.wml deleted file mode 100644 index f5f97cfe720..00000000000 --- a/greek/devel/wnpp/help_requested_bypop.wml +++ /dev/null @@ -1,18 +0,0 @@ -#use wml::debian::template title="Packages for which help was requested, organized by popularity" GEN_TIME="true" -#use wml::debian::translation-check translation="2e1044712299f75aac55782c35ffe2ebce9eb3e5" maintainer="galaxico" - -#include "$(ENGLISHDIR)/devel/wnpp/wnpp.data" - -<p> -This list is also available organized -<a href="help_requested">by package name</a> or -<a href="help_requested_byage">by age</a>. -</p> - -<help_req_bypop /> - -<p> -This list is also available organized -<a href="help_requested">by package name</a> or -<a href="help_requested_byage">by age</a>. -</p> diff --git a/greek/devel/wnpp/index.wml b/greek/devel/wnpp/index.wml deleted file mode 100644 index 495834a1949..00000000000 --- a/greek/devel/wnpp/index.wml +++ /dev/null @@ -1,384 +0,0 @@ -#use wml::debian::template title="Work-Needing and Prospective Packages" -#use wml::debian::toc -#include "$(ENGLISHDIR)/devel/wnpp/wnpp.data" -#use wml::debian::translation-check translation="ff76decf22b833c8b721fc40392935030d5f2a2b" maintainer="galaxico" - -<define-tag toc-title-formatting endtag=required><h3>%body</h3></define-tag> - -<p>Work-Needing and Prospective Packages, WNPP for short, is a list -of packages in need of new maintainers and prospective packages in Debian. -In order to closely track the real status of such things, WNPP is currently -operated as a pseudo-package in the <a href="https://bugs.debian.org/">Debian -Bug Tracking System (BTS)</a>.</p> - -<hrline /> - -<p><a href="work_needing">Packages in need of a new maintainer</a>: -</p> -<ul> - <li> - <a href="rfa_bypackage"><rfa_number> packages up for adoption</a>, - organized <a href="rfa_bymaint">by maintainer</a> - or <a href="rfa_byage">by age</a> - </li> - <li> - <a href="orphaned"><orphaned_number> orphaned packages</a>, - organized <a href="orphaned_byage">by age</a> - </li> - <li> - <a href="being_adopted"><adopted_number> packages currently being adopted</a>, - organized <a href="being_adopted_byage">by age</a> - or <a href="being_adopted_byactivity">by activity</a> - </li> -</ul> - -<p> -<a href="help_requested"><help_number> packages in need of help</a>, -organized <a href="help_requested_byage">by age</a> -or <a href="help_requested_bypop">by popularity</a> -</p> - -<p><a href="prospective">Prospective packages</a>:</p> -<ul> - <li> - <a href="being_packaged"><packaged_number> packages being worked on</a>, - organized <a href="being_packaged_byage">by age</a> - or <a href="being_packaged_byactivity">by activity</a> - </li> - <li> - <a href="requested"><requested_number> requested packages</a>, - organized <a href="requested_byage">by age</a> - </li> -</ul> - - -<p>Note: these lists are updated six times a day; for more up-to-date information -please check the <a href="https://bugs.debian.org/wnpp">wnpp pseudo package</a> -entry in the BTS.</p> - -<p>You can search the above information by package, description or type -on the <a href="https://wnpp.debian.net">WNPP search</a> website.</p> - -<p>You can browse the above information broken down into various categories -(based on <a href="https://debtags.debian.org/">debtags</a>) on the -<a href="https://wnpp-by-tags.debian.net">WNPP-by-tags</a> website.</p> - -<hrline /> - -<h2>Using WNPP</h2> - -<toc-display /> - -<p>Since it uses the BTS, every developer is already familiar with the -technical details, such as submission of new information, modification of -information or closing of pending requests. On the other hand, in order to -achieve the highest level of automatization, some procedures have to be -observed.</p> - -<p>In order to submit new information, a bug has to be filed against the -<a href="https://bugs.debian.org/wnpp">wnpp pseudo package</a> for each -(prospective) package that is affected. Please note that you should -only submit one bug per source package rather than one bug for each -binary package built from a source package.</p> - - -<toc-add-entry>Adding new entries with <q>reportbug</q></toc-add-entry> - -<p>You can use <a href="https://packages.debian.org/reportbug">reportbug</a> -(<kbd>apt-get install reportbug</kbd>):</p> - -<samp> - $ reportbug --email <var>username@domain.tld</var> wnpp<br /> - Using '<var>Your Name <username@domain.tld></var>' as your from address.<br /> - Getting status for wnpp...<br /> - Querying Debian bug tracking system for reports on wnpp<br /> - (Use ? for help at prompts.)<br /> - ...<br /> -</samp> - -<p>You will see a list of reported bugs against WNPP which you -should read to prevent a second report for the same package.</p> -<p>After the buglist you are asked for the request type:</p> - -<samp> -What sort of request is this?<br /> -<br /> -1 ITP This is an <q>Intent To Package</q>. Please submit a package description<br /> - along with copyright and URL in such a report.<br /> -<br /> -2 O The package has been <q>Orphaned</q>. It needs a new maintainer as soon<br /> - as possible.<br /> -<br /> -3 RFA This is a <q>Request for Adoption</q>. Due to lack of time, resources,<br /> - interest or something similar, the current maintainer is asking for<br /> - someone else to maintain this package. They will maintain it in<br /> - the meantime, but perhaps not in the best possible way. In short:<br /> - the package needs a new maintainer.<br /> -<br /> -4 RFH This is a <q>Request For Help</q>. The current maintainer wants to continue<br /> - to maintain this package, but he/she needs some help to do this, because<br /> - his/her time is limited or the package is quite big and needs several<br /> - maintainers.<br /> -<br /> -5 RFP This is a <q>Request For Package</q>. You have found an interesting piece<br /> - of software and would like someone else to maintain it for Debian.<br /> - Please submit a package description along with copyright and URL in<br /> - such a report.<br /> -<br /> -Choose the request type: <br /> -</samp> - -<p>After your selection you will be asked for the package name:</p> - -<samp> -Choose the request type: <var>x</var><br /> -Please enter the proposed package name: <var>PACKAGENAME</var><br /> -Checking status database...<br /> -</samp> - -<ul> -<li><p>If your request type is ITP (1) or RFP (5) you are asked for a short - description and then for some information about the package:</p> - -<samp> -Please briefly describe this package; this should be an appropriate short -description for the eventual package:<br /> -> <var>A DESCRIPTION</var><br /> -<br /> -Subject: ITP: <var>PACKAGENAME -- A DESCRIPTION</var><br /> -Package: wnpp<br /> -Version: N/A; reported 2002-01-30<br /> -Severity: wishlist<br /> -<br /> -* Package name : <var>PACKAGENAME</var><br /> - Version : <var>x.y.z</var><br /> - Upstream Author : <var>Name <somebody@some.org></var><br /> -* URL : <var>http://www.some.org/</var><br /> -* License : <var>(GPL, LGPL, BSD, MIT/X, etc.)</var><br /> - Description : <var>A DESCRIPTION</var><br /> -<br /> -<br /> --- System Information<br /> -...<br /> -</samp> - -<p>Below the <q>Description</q> line you should give more information -about the package.</p></li> - -<li><p>If your request type is O (2) or RFA (3) you have to enter the name -of the package.</p> - -<samp> -Choose the request type: <var>x</var><br /> -Please enter the name of the package: <var>PACKAGENAME</var><br /> -Checking status database...<br /> -<br /> -Subject: O: <var>PACKAGENAME -- SHORT DESCRIPTION</var><br /> -Package: wnpp<br /> -Version: N/A; reported 2002-01-30<br /> -Severity: normal<br /> -<br /> -<br /> -<br /> --- System Information<br /> -...<br /> -</samp> - -<p>You should add some information about maintaining the package, the upstream -situation and maybe a reason why you want to give the package away.</p></li> - -</ul> - -<p>Then you are asked if you want to send your request:</p> - -<samp> -Report will be sent to Debian Bug Tracking System <submit@bugs.debian.org><br /> -Submit this bug report (e to edit) [Y|n|i|e|?]? <br /> -</samp> - - -<toc-add-entry>Adding new entries via email</toc-add-entry> - -<p>It is also possible to report reports/bugs against the WNPP via email. -The format of the submission should be like this:</p> - -<samp> - To: submit@bugs.debian.org<br /> - Subject: <var>TAG</var>: <var>package name</var> -- <var>short package description</var><br /> - <br /> - Package: wnpp<br /> - Severity: <var>see below</var><br /> - <br /> - <var>Some information about the package.</var> (If this is an ITP or RFP a URL - where the package (either the .deb or the original source) can be downloaded - from is required, as well as - information concerning its license.) -</samp> - -<p>The tags to be used and their corresponding severities are:</p> - -<table> -<colgroup span="3"> -<col width="10%"> -<col width="10%"> -<col width="80%"> -</colgroup> -<tr> - <th valign="top"><a name="tag-o">O</a></th> - <td valign="top"><em>normal</em></td> - <td>The package has been <q>Orphaned</q>. It needs a new maintainer - as soon as possible. If the package has a Priority higher or equal to - standard, the severity should be set to important. - </td> -</tr> -<tr> - <th valign="top"><a name="tag-rfa">RFA</a></th> - <td valign="top"><em>normal</em></td> - <td>This is a <q>Request for Adoption</q>. Due to lack of time, - resources, interest or something similar, the current maintainer is - asking for someone else to maintain this package. They will maintain - it in the meantime, but perhaps not in the best possible way. - In short: the package needs a new maintainer. - </td> -</tr> -<tr> - <th valign="top"><a name="tag-rfh">RFH</a></th> - <td valign="top"><em>normal</em></td> - <td>This is a <q>Request For Help</q>. The - current maintainer wants to continue to maintain this package, - but they need some help to do this, because their time is limited - or the package is quite big and needs several maintainers. - </td> -</tr> -<tr> - <th valign="top"><a name="tag-itp">ITP</a></th> - <td valign="top"><em>wishlist</em></td> - <td>This is an <q>Intent To Package</q>. Please submit a package - description along with copyright and URL in such a report. - </td> -</tr> -<tr> - <th valign="top"><a name="tag-rfp">RFP</a></th> - <td valign="top"><em>wishlist</em></td> - <td>This is a <q>Request For Package</q>. Someone has found an - interesting piece of software and would like someone else to maintain - it for Debian. Please submit a package description along with - copyright and URL in such a report. - </td> -</tr> -</table> - - -<toc-add-entry>Removing entries</toc-add-entry> - -<p>The procedures for closing these bugs are as follows: -</p> - -<table> -<colgroup span="2"> -<col width="10%"> -<col width="90%"> -</colgroup> -<tr> - <th valign="top"><a name="howto-o">O</a></th> - <td>If you are going to adopt a package, retitle its bug - to replace <q>O</q> with <q>ITA</q>, in order for other people to know the - package is being adopted and to prevent its automatic removal from the - archive, and set yourself as the owner of the bug. - To actually adopt the package, upload it with your name in - its Maintainer: field, and put something like - <code> - * New maintainer (Closes: #<var>bugnumber</var>) - </code> - in the changelog of the package in order to automatically close this - bug once the package has been installed; where <var>bugnumber</var> - has to be replaced with the corresponding bugreport number. - Furthermore, before you - actually upload a new package with you as the maintainer, you should - check if there is a new upstream release and you should try to fix the - outstanding bugs. - </td> -</tr> -<tr> - <th valign="top"><a name="howto-rfa">RFA</a></th> - <td><p>If you are going to adopt a package, retitle its bug - to replace <q>RFA</q> with <q>ITA</q>, in order for other people to know the - package is being adopted and to prevent its automatic removal from the - archive, and set yourself as the owner of the bug. - To actually adopt the package, upload it with your name in - its Maintainer: field, and close this bug once the package has been - installed. - </p> - - <p>If you as the package maintainer decide to orphan the package you - marked with <q>RFA</q>, please retitle the bug report and replace <q>RFA</q> - with <q>O</q>. If you withdraw your request, please close the bug.</p> - </td> -</tr> -<tr> - <th valign="top"><a name="howto-rfh">RFH</a></th> - <td><p>Normally this bug should only closed by the - submitter, i.e. the package maintainer, if they consider it - obsolete, either because one or more people have offered - (and provided) their support or because they now think that - they can handle the package for themself. - </p> - - <p>If you as the package maintainer decides to change the RFH to - a request for adoption (<q>RFA</q>) or if you want to - orphan the package (<q>O</q>), please retitle the bug - instead of closing it and filing a new one.</p> - </td> -</tr> -<tr> - <th valign="top"><a name="howto-itp">ITP</a></th> - <td><p>package the software, upload it and close this bug once - the package has been installed. - </p> - - <p>If you change your mind, and no longer want to package this, either - close the bug or retitle and reclassify it as RFP, as you see fit.</p> - - <p>If you encounter problems with packaging the program (for example it - depends on another, not-yet-packaged program which you don't have - time to package), you might want to record these problems - as additional information in the ITP, so that it is clear what's going on with - your packaging efforts.</p> - </td> -</tr> -<tr> - <th valign="top"><a name="howto-rfp">RFP</a></th> - <td>If you are going to package this, retitle the bug report - to replace <q>RFP</q> with <q>ITP</q>, in order for other people to know the - program is already being packaged, and set yourself as the owner of - the bug. Then package the software, upload it and close this bug once - the package has been installed. - </td> -</tr> -</table> - -<p>If you feel that the developers' mailing list should know about your ITP, -RFA or anything else, add the header</p> -<pre>X-Debbugs-CC: debian-devel@lists.debian.org</pre> -<p>to the message.</p> - -<p>Of course, the easiest way of closing these bugs is to include an entry -in the package changelog saying what you've done and append -<tt>(closes: bug#nnnnn)</tt> to it. This way the bug will be closed -automatically after the new package gets installed into the archive.</p> - -<p> -<strong>Attention:</strong> if you need to reassign, retitle, or set the -owner of bug reports, you must do so by emailing the BTS control bot -<a href="$(HOME)/Bugs/server-control">directly</a> or by emailing the report -number @bugs.debian.org and using -<a href="$(HOME)/Bugs/Reporting#control">Control pseudo-headers</a>, -but <strong>not</strong> by filing new reports. -</p> - -<p>Note: if a package remains orphaned for a very long time, we will examine -the situation to determine if the package is needed anymore — if not, -the FTP maintainers will be asked to remove the package from unstable.</p> - -<p>If for some reason you need to contact the WNPP maintainers, they can be -reached at <email wnpp@debian.org>.</p> diff --git a/greek/devel/wnpp/orphaned.wml b/greek/devel/wnpp/orphaned.wml deleted file mode 100644 index 222c6150ddc..00000000000 --- a/greek/devel/wnpp/orphaned.wml +++ /dev/null @@ -1,16 +0,0 @@ -#use wml::debian::template title="Orphaned packages" GEN_TIME="true" -#use wml::debian::translation-check translation="9c91dafe36ecc3ea323c52c9c21d02f91dca4751" maintainer="galaxico" - -#include "$(ENGLISHDIR)/devel/wnpp/wnpp.data" - -<p> -This list is also available organized -<a href="orphaned_byage">by age</a>. -</p> - -<orphaned /> - -<p> -This list is also available organized -<a href="orphaned_byage">by age</a>. -</p> diff --git a/greek/devel/wnpp/orphaned_byage.wml b/greek/devel/wnpp/orphaned_byage.wml deleted file mode 100644 index 36632902bd3..00000000000 --- a/greek/devel/wnpp/orphaned_byage.wml +++ /dev/null @@ -1,16 +0,0 @@ -#use wml::debian::template title="Orphaned packages, by age" GEN_TIME="true" -#use wml::debian::translation-check translation="9c91dafe36ecc3ea323c52c9c21d02f91dca4751" maintainer="galaxico" - -#include "$(ENGLISHDIR)/devel/wnpp/wnpp.data" - -<p> -This list is also available organized -<a href="orphaned">by package name</a>. -</p> - -<orphaned_byage /> - -<p> -This list is also available organized -<a href="orphaned">by package name</a>. -</p> diff --git a/greek/devel/wnpp/prospective.wml b/greek/devel/wnpp/prospective.wml deleted file mode 100644 index b5c5029e162..00000000000 --- a/greek/devel/wnpp/prospective.wml +++ /dev/null @@ -1,10 +0,0 @@ -#use wml::debian::template title="Prospective packages" GEN_TIME="true" -#use wml::debian::translation-check translation="f49611cb55aa09fd5351490070f08bc13071863c" maintainer="galaxico" - -#include "$(ENGLISHDIR)/devel/wnpp/wnpp.data" - -<h3>Packages being worked on</h3> -<being_packaged /> - -<h3>Requested packages</h3> -<requested /> diff --git a/greek/devel/wnpp/requested.wml b/greek/devel/wnpp/requested.wml deleted file mode 100644 index 8803a594dc5..00000000000 --- a/greek/devel/wnpp/requested.wml +++ /dev/null @@ -1,16 +0,0 @@ -#use wml::debian::template title="Requested packages" GEN_TIME="true" -#use wml::debian::translation-check translation="9c91dafe36ecc3ea323c52c9c21d02f91dca4751" maintainer="galaxico" - -#include "$(ENGLISHDIR)/devel/wnpp/wnpp.data" - -<p> -This list is also available organized -<a href="requested_byage">by age</a>. -</p> - -<requested /> - -<p> -This list is also available organized -<a href="requested_byage">by age</a>. -</p> diff --git a/greek/devel/wnpp/requested_byage.wml b/greek/devel/wnpp/requested_byage.wml deleted file mode 100644 index 55920baf1b1..00000000000 --- a/greek/devel/wnpp/requested_byage.wml +++ /dev/null @@ -1,16 +0,0 @@ -#use wml::debian::template title="Requested packages, organized by age" GEN_TIME="true" -#use wml::debian::translation-check translation="9c91dafe36ecc3ea323c52c9c21d02f91dca4751" maintainer="galaxico" - -#include "$(ENGLISHDIR)/devel/wnpp/wnpp.data" - -<p> -This list is also available organized -<a href="requested">by package name</a>. -</p> - -<requested_byage /> - -<p> -This list is also available organized -<a href="requested">by package name</a>. -</p> diff --git a/greek/devel/wnpp/rfa_byage.wml b/greek/devel/wnpp/rfa_byage.wml deleted file mode 100644 index 2e985b77d80..00000000000 --- a/greek/devel/wnpp/rfa_byage.wml +++ /dev/null @@ -1,18 +0,0 @@ -#use wml::debian::template title="Packages up for adoption, organized by age" GEN_TIME="true" -#use wml::debian::translation-check translation="9c91dafe36ecc3ea323c52c9c21d02f91dca4751" maintainer="galaxico" - -#include "$(ENGLISHDIR)/devel/wnpp/wnpp.data" - -<p> -This list is also available organized -<a href="rfa_bypackage">by package name</a> or -<a href="rfa_bymaint">by maintainer</a>. -</p> - -<rfa_byage /> - -<p> -This list is also available organized -<a href="rfa_bypackage">by package name</a> or -<a href="rfa_bymaint">by maintainer</a>. -</p> diff --git a/greek/devel/wnpp/rfa_bymaint.wml b/greek/devel/wnpp/rfa_bymaint.wml deleted file mode 100644 index 0fd14f83da7..00000000000 --- a/greek/devel/wnpp/rfa_bymaint.wml +++ /dev/null @@ -1,18 +0,0 @@ -#use wml::debian::template title="Packages up for adoption, organized by maintainer" GEN_TIME="true" -#use wml::debian::translation-check translation="9c91dafe36ecc3ea323c52c9c21d02f91dca4751" maintainer="galaxico" - -#include "$(ENGLISHDIR)/devel/wnpp/wnpp.data" - -<p> -This list is also available organized -<a href="rfa_bypackage">by package name</a> or -<a href="rfa_byage">by age</a>. -</p> - -<rfa_bymaint /> - -<p> -This list is also available organized -<a href="rfa_bypackage">by package name</a> or -<a href="rfa_byage">by age</a>. -</p> diff --git a/greek/devel/wnpp/rfa_bypackage.wml b/greek/devel/wnpp/rfa_bypackage.wml deleted file mode 100644 index 41a2478ee7d..00000000000 --- a/greek/devel/wnpp/rfa_bypackage.wml +++ /dev/null @@ -1,18 +0,0 @@ -#use wml::debian::template title="Packages up for adoption" GEN_TIME="true" -#use wml::debian::translation-check translation="9c91dafe36ecc3ea323c52c9c21d02f91dca4751" maintainer="galaxico" - -#include "$(ENGLISHDIR)/devel/wnpp/wnpp.data" - -<p> -This list is also available organized -<a href="rfa_bymaint">by maintainer</a> or -<a href="rfa_byage">by age</a>. -</p> - -<rfa_bypackage /> - -<p> -This list is also available organized -<a href="rfa_bymaint">by maintainer</a> or -<a href="rfa_byage">by age</a>. -</p> diff --git a/greek/devel/wnpp/unable-hdate.wml b/greek/devel/wnpp/unable-hdate.wml deleted file mode 100644 index 898f35651be..00000000000 --- a/greek/devel/wnpp/unable-hdate.wml +++ /dev/null @@ -1,28 +0,0 @@ -#use wml::debian::template title="Unable to be packaged: hdate" -#use wml::debian::translation-check translation="6f3adf6374f35194686f89dec2ba66b1ecf3bb5f" maintainer="galaxico" - -<h3>hdate — Prints Hijra (Islamic lunar) dates, calendar, Islamic prayer times</h3> - -<p>This package contains more than one licence -and they stand in conflict with each other.</p> - -<p>The source archive contains file licensed under the <a -href="https://www.gnu.org/copyleft/gpl.html">GNU General Public -License</a> (GPL) but some source files also contain the following -note:</p> - -<pre> - * Permission for nonprofit use and redistribution of this software and - * its documentation is hereby granted without fee, provided that the - * above copyright notice appear in all copies and that both that - * copyright - * notice and this permission notice appear in supporting - * documentation. -</pre> - -<p>The author says that he is not prepared to re-release the entire -software under the GPL and explicitly asserts that the software is -available for use without charge for non-profit use only.</p> - -<p>This problem has been discussed in <a -href="https://bugs.debian.org/225537">Bug#225537</a>.</p> diff --git a/greek/devel/wnpp/work_needing.wml b/greek/devel/wnpp/work_needing.wml deleted file mode 100644 index 25153bf5fa0..00000000000 --- a/greek/devel/wnpp/work_needing.wml +++ /dev/null @@ -1,13 +0,0 @@ -#use wml::debian::template title="Packages in need of a new maintainer" GEN_TIME="true" -#use wml::debian::translation-check translation="f49611cb55aa09fd5351490070f08bc13071863c" maintainer="galaxico" - -#include "$(ENGLISHDIR)/devel/wnpp/wnpp.data" - -<h3>Packages up for adoption</h3> -<rfa_bypackage /> - -<h3>Packages up for adoption, by maintainer</h3> -<rfa_bymaint /> - -<h3>Orphaned packages</h3> -<orphaned /> |