DEUTSCH: Bounty-Regeln

Prämiensystem zur Umsetzung diverser Projekte / Offer a reward for various projects

Moderatoren: analogkid, roschmyr, ThePlayer, insane

Benutzeravatar
insane
Administrator
Administrator
Beiträge: 603
Registriert: 04 Mai 2004, 20:32
Wohnort: Kiel

DEUTSCH: Bounty-Regeln

Beitragvon insane » 28 Jul 2008, 23:55

Pegasosforum Bounty-Team Regeln v0.06 - Sonnabend, 26.Juli 2008


DISCLAIMER:

Dieses hier sind die Regeln für das Bounty-System, welches im Forum
http://www.pegasosforum.de entstanden sind (im weiteren PF genannt). Die meisten
von ihnen stammen aus der MorphZone (http://www.morphzone.org) oder wurden aus
dieser übernommen und an unsere Bedürfnisse angepasst.


REGELN:

1 Wie wird eine Bounty eingereicht und akzeptiert?

Die einreichende Person muss eine Beschreibung als Thread in der "BountyBay" des
PF schreiben, oder diese direkt an bounty-team@amigaclubhamburg.de schicken.
Die Beschreibung muss das Ziel, die Mindest-Voraussetzungen sowie optionale
Funktionen der Bounty beinhalten. Eine Vorlage für diese Beschreibung ist auf
Anfrage beim Bounty-Team erhältlich.


2 Der Minimalbetrag zum Öffnen einer Bounty beträgt 25 EUR

Die vorgeschlagene Bounty wird von dem Bounty-Team überprüft, ob sie erfüllbar
ist. Im Folgenden wird das Team den Autor informieren, ob sein/ihr Projekt
akzeptiert wurde, ob es Änderungen bedarf oder ob es abgelehnt wurde. Wenn
akzeptiert, wird der Bounty-Status auf "open" (eröffnet) gesetzt und bei
erfolgtem Geldtransfer veröffentlicht.


3 Wie übernimmt ein Entwickler eine Bounty?

Zunächst muss der Status der Bounty auf "open" (eröffnet) sein. Dann kann der
interessierte Entwickler eine Nachricht an das Bounty-Team senden.
bounty-team@amigaclubhamburg.de

Wenn mehr als ein Entwickler interessiert sein sollte, wird das Bounty-Team mit
den jeweiligen Interessen diskutieren, welcher der Interessenten zum Erfüllen
der Bounty geeignet zu sein scheint. Wenn das Ziel einer Bounty sein sollte,
einer bereits erfüllten Bounty oder anderen, bestehenden Anwendung neue
Funktionen zu verschaffen, dann wird der ursprüngliche Entwickler bevorzugt
behandelt.

Die Arbeit an einer Bounty ist nicht auf einzelne Entwickler beschränkt, auch
ein Team kann an dieser arbeiten. Ein Entwickler dieses Teams sollte mit dem
Bounty-Team Kontakt aufnehmen und der Leiter der Projekts sein. Im Falle einer
Auszahlung muss er die Zahlung bzw. Verteilung des Bounty-Betrages innerhalb des
Teams vornehmen.


Sobald sich das Bounty-Team und der Entwickler geeinigt haben, wird der
Bounty-Status auf "assigned" (zugewiesen) gesetzt. Für jede zugewiesende Bounty
bleibt jeweils ein Mitglied des Bounty-Teams mit dem Entwickler in Kontakt, so
dass beispielsweise Änderungen hinsichtlich des Bounty-Status im jeweiligen
Thread im PF berichtet werden können.

Der Entwickler muss einmal im Monat einen Bericht über den Status der in Angriff
genommenen Bounty liefern, um das Fortschreiten der Entwicklung sicherzustellen.



4 Was muss der Entwickler liefern?

Ziel ist es, eine MorphOS-native Distribution bzw. Archiv zur Erfüllung der
Bounty zu liefern, bestehend aus Objektdateien, Dokumentation und
Installerskript, welches unter MorphOS 1.4.5 oder neuer läuft. Die Lösung muss
frei zur Benutzung für alle MorphOS-Benutzer sein. Natürlich darf es nicht gegen
bestehende Rechte dritter Parteien verstossen.

Diese Distributionen bzw. Archive werden anschließlich über das Pegasosforum
oder das Aminet verfügbar sein. Der Entwickler sollte sein möglichstes tun,
Fehler und nicht-systemkonformes Verhalten des Programmes zu vermeiden bzw.
diese zu korrigieren, wenn sie vom Bounty-Team vorgeschlagen werden.


Um die Distribution auch zukünftig pflegen zu können, wird der Entwickler auch
den Quellkode sowie die verwendete Entwicklungsumgebung zur Verfügung stellen
müssen. Bevorzugt wird ein Standard-Makefile, das mit dem gewöhnlichen
MorphOS-SDK zusammenarbeitet. Der Quellkode geht in den Besitz des Bounty-Teams
über. Wenn sich der Autor dazu entscheidet, den Quellkode der Applikation nicht
freizugeben, dann wird der Kode erst dann verwendet, wenn sich der Autor dazu
entschliesst, die Applikation aufzugeben und keine weiteren Updates
bereitzustellen.

Um das Entwicklerinteresse zu steigern, wird das Bounty-Team sowohl Open-Source
als auch Closed-Source unterstützen. Der Entwickler kann dabei frei wählen,
welche Lizenz er verwendet, solange sie nicht in Konflikt mit den
PF-Bountyregeln oder anderen Lizenzen (z.B. GPL) steht.

Wenn er sich für das Closed-Source-Modell entscheidet, wird sein Quellkode nicht
freigegeben, außer:

- Wenn der ursprüngliche Entwickler nicht mehr verfügbar ist, um notwendige
Änderungen durchzuführen, wenn sein Programm unter den jeweilig aktuellen
Umständen seinen Dienst nicht mehr verrichtet (z.B. im Zuge eines neuen
MorphOS-Release oder aufgrund einer Situation, die beim ersten Release der
Distribution nicht abgeschätzt werden konnte).

- Wenn eine neue Bounty einem neuen Entwickler zugewiesen wurde, der der
vollständigen Bounty neue Funktionen hinzufügt.

Der neue Entwickler wird die Verpflichtung haben, den Quellkode ebenfalls
verschlossen zu halten und die Verwendung auf die Bounty zu beschränken.


4.1 Allgemeine Anforderungen an den Bountys

Alle Programme müssen allgemeinen Kriterien und MorphOS-spezifischen
Systemstandards folgen, die da wären:

1) Alle Benutzeroberflächen müssen auf MUI basieren.
2) Jedes Programm muss vollständige Unterstützung des Locale-Systems bieten.
Englisch kann die eingebaute Standard-Sprache sein, andere Sprachen können auch
beigefügt werden.
3) Shell-Programme müssen dem Format für DOS-Templates folgen, um vollständig
mit "R" genutzt werden zu können.
4) Programme müssen entweder aus ihrem eigenen Verzeichnis lauffähig sein oder
mit Hilfe des Installers installierbar sein, der im Aminet unter
http://aminet.net/package/util/misc/Installer-43_3 zu finden ist.
5) Die Mindestanforderungen für die Lauffähigkeit des Programms ist MorphOS
1.4.5.

Für einzelne Treiber/Datatypes/Reggae-Klassen oder ähnliches können die Punkte
1) - 4) außer acht gelassen werden.

Jedes Bounty-Projekt muss mit einem Mindestmaß an Dokumentation daherkommen, um
es auch weniger bedarften und erfahrenen Benutzern zu ermöglichen, die
Applikation ohne große Umstände zu verwenden. Aus diesem Grund muss das Archiv
bzw. die Distribution zumindest eine englische Readme-Datei im üblichen Format
für Aminet-Readme-Dateien enthalten. In diesem sollte beschrieben werden, welche
zusätzlichen Bibliotheken, Treiber oder ähnliches benötigt werden, um das
Programm zu verwenden. Für weitere Dokumentation kann das Format frei gewählt
werden, solange es unter MorphOS 1.4.5 lesbar ist (z.B. normaler ASCII-Text,
HTML, AmigaGuide oder PDF, solange Apdf mit der Datei klarkommt).

Entwickler müssen monatlich zum Stichtag der Bounty-Übernahme einen sinnvollen
Status-Bericht schreiben. Zweck ist es, Projekte im angemessenen Zeitrahmen zu
halten und sie bei Bedarf neu zuweisen zu können.


5 Wann wird die Zahlung an den Entwickler erfolgen?

Zunächst muss der Entwickler die Distribution (Archiv mit Binärdateien,
Dokumentation und Quellkode) an das Bounty-Team senden, welches diese zunächst
prüft. Wenn es der Autor wünscht, wird der Quellkode intern behalten. Im Falle
einer Closed-Source Applikation ist die funktionierende Binärdatei erforderlich.

In der folgenden Woche wird das Bounty-Team überprüfen, ob die Distribution das
Ziel erreicht. Wenn die Mitglieder nicht das erforderliche Equipment zum Testen
haben (z.B. im Falle eines Treibers), wird die Erlaubnis vom Entwickler
eingeholt, den Treiber an jemanden zu geben, der den Test durchführen kann.

Dann wird der Quellkode von einem Entwickler des Bounty-Teams auf
Systemkonformität und Zukunftssicherheit überprüft. Natürlich muss der Autor
seinen Quellkode nicht offenlegen, wenn er das nicht wünscht.

Sobald festgestellt wurde, dass alles gemäß der Regeln fertiggestellt wurde,
wird eine Zahlung an den Entwickler veranlasst. Die bevorzugte Zahlungsweise ist
PayPal. Banktransfer ist ebenfalls möglich, allerdings müssen hierbei eventuelle
Überweisungsgebühren berücksichtigt werden, abhängig vom Heimatland des
Entwicklers. Bei erfolgtem Zahlungseingang wird die Distribution (und im Falle
von Open-Source auch der Quellkode) allgemein verfügbar gemacht.


6 Was passiert, wenn eine Bounty nicht erfüllt werden kann?

Von Zeit zu Zeit werden die Mitglieder des Bounty-Teams die Situation der
Bountys abschätzen. Wenn entschieden wird, dass eine bestimmte Bounty zu lange
offen ist und es keine Chance besteht, dass diese erfüllt wird, so werden die
Spender gefragt, was alternativ mit dem Geld gemacht werden darf. Es gibt dabei
zwei Optionen. Zum einen kann das gespendete Geld einem anderen Projekt
zugewiesen werden, oder das Geld kann an den Spender zurücküberwiesen werden. Im
letzeren Fall muss eine kleine Gebühr für PayPal abgezogen werden. Wenn auch die
alternative Bounty nicht erfüllt werden kann, landet das Geld in einem
allgemeinen Fond, der für andere/neue Bountys verwendet wird.

WICHTIG!! der einzige Weg, uns über die bevorzugte Wahl der Verwendung zu
unterrichten, ist das Formular "alternative Bounty / Cash Back?" auf der
PayPal-Siete auszufüllen. Wenn dieses Formular nicht verwendet wird, kann das
Geld nicht zurückgeschickt werden! Es wird dann in den allgemeinen Fond
transferiert.


NB: Diese Regeln können in Zukunft angepasst werden, sobald neue Gegebenheit
entstehen oder unbeantwortete Fragen aufkommen. Unser Ziel ist es, sowohl die
Interessen der Spender als auch die der Entwickler zu wahren.

Zurück zu „Bounty Bay“



Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 0 Gäste