Posts Tagged ‘ Projekte

Update: Projekt “Icy Tracker” – Kurze Zwischenmeldung

Also nicht, dass sich einige wundern, warum es gerade keine Updates zum Icy Tracker gibt:
Ich bin im Moment wegen eines größeren Projektes ein wenig ausgelastet, deswegen habe ich den Icy Tracker ein wenig zurückgestellt. Sobald das andere Projekt einen bestimmten Stand erreicht hat, gehen die Arbeiten am Icy Tracker wieder auf Hochtouren weiter.

Zudem wird es noch einige grundsätzliche Veränderungen am Projekt „Icy Tracker“ geben, die dem Projekt sicher förderlich sind, aber dazu später mehr, sobald es spruchreif ist. 😉

Update: Projekt „Icy Tracker“ – Erste Bilder vom ACP

Da ich an diesem Wochenende einiges geschafft habe, dachte ich mir, ich könnte euch ein paar erste Screenshots aus dem ACP mit auf den Weg geben.
Viel Spaß mit den Bildern.

Update: Projekt „Icy Tracker“

Da ich im Moment leider nicht die Zeit habe, die ich gerne in das Projekt rein stecken würde, habe ich mich dazu entschieden erst einmal eine „kleine“ Version zu schreiben, die nicht alle geplanten Features haben wird. Diese „kleine“ Version wird die 1.0 sein und den Codenamen „Gennam“ tragen, was Germanisch für „Anfang“ ist.

Gennam wird dabei so minimalistisch wie möglich gehalten. Es wird nur Projekte und keine Kategorien geben. Die Tickettypen werden fest sein, genauso wie die Prioritäten, die Status (Ja, das ist der Plural von Status), die Prioritäten und die Lösungen für geschlossene Tickets. Es wird keine Benutzerdefinierten Felder für Tickets geben und es steht noch nicht fest, ob man Tickets verknüpfen können wird, aber ich denke, das wird kommen.

Ein Ticket wird bestehen aus:

  • Titel / Kurzbeschreibung
  • Typ
  • Status
  • Priorität
  • Bearbeiter
  • Betroffene Version(en)
  • Lösung (wenn das Ticket geschlossen/behoben/umgesetzt wurde)
  • Version in der das Problem behoben/das Feature implementiert ist (wenn das Ticket geschlossen/behoben/umgesetzt wurde)
  • Sichtbarkeit (damit kritische Fehler nur für den „Melder“ und die Entwickler zu sehen sind)
  • Beschreibung

Zusätzlich werden sie Anhänge und Kommentare enthalten können und Feature Requests werden vermutlich zusätzlich eine „Möchte ich auch“-Funktion haben.

Die möglichen Tickettypen werden nach der aktuellen Planung folgende werden:

  • Bug/Fehler
  • Feature Request (kann mir jemand dafür eine korrekte und zugleich passende Übersetzung nennen?)
  • Aufgabe

Die Status werden nach der aktuellen Planung folgende werden:

  • Neu
  • Bestätigt
  • In Arbeit
  • Behoben/Umgesetzt
  • Geschlossen

Die Lösungen zu den Status Behoben/Umgesetzt und Geschlossen werden nach aktueller Planung wie folgt heißen:

  • Behoben
  • Lösung verschoben
  • Wird nicht behoben/umgesetzt
  • Nicht reproduzierbar
  • Kein Fehler
  • Duplikat

Die Prioritäten werden nach aktueller Planung wie folgt lauten:

  • Kritisch
  • Hoch
  • Normal
  • Niedrig
  • Keine

Die angegeben Typen, Status, Lösungen und Prioritäten können sich noch teilweise ändern und ich freue mich selbstverständlich auch über Anregungen. Vielleicht fällt euch ja noch der eine oder andere Status o.Ä. ein, welcher unbedingt noch mit rein muss.

Ich hoffe, ich konnte euch einen kleinen Überblick verschaffen. Wenn ihr noch fragen habt könnt ihr diese gerne als Kommentar oder an die im Impressum angegebene E-Mail Adresse stellen.

Eine kleine Bitte

Aus aktuellem Anlass muss ich das folgende zu meinem WCF Projekten einfach mal zusätzlich hier im Blog veröffentlichen:

Sollten Ihnen Fehler in einem meiner Pakete auffallen, melden Sie diese bitte in unserem Bugtracker, um zu gewährleisten, dass diese möglichst zeitnah bearbeitet werden können.

Ich verlange keinerlei finanzielle Gegenleistung für die Nutzung meiner Pakete und stelle diese unter die LGPL, damit sie frei genutzt und angepasst werden können. Da eine Bearbeitung von Problemen und Wünschen und die damit vorhandene Organisation gerade bei vielen Paketen in Foren wie diesen, bzw. allgemein in Foren äußerst mühsam ist, verlange ich lediglich, dass Fehler in unserem Bugtracker gemeldet werden.
Ein Bugtracker vereinfacht das Arbeiten mit und die Organisation von Softwareprojekten ungemein und das nicht nur für den Entwickler, sondern auch für den Anwender. Zudem sind der Entwickler und der Anwender durch die umfangreichen E-Mail Benachrichtigungen stets über neue Entwicklungen am Ticket informiert.
Ich habe mich dabei für ein auch für den Anwender einfach zu nutzendes System entschieden und mich dafür eingesetzt dieses für unsere Open Source Projekte zu bekommen. Normalerweise kostet das System in dem Umfang mehrere hundert Dollar pro Jahr, man kann aber unter bestimmten Voraussetzungen eine für Open Source Projekte kostenlose Lizenz erhalten. Wir haben diese Voraussetzungen extra geschaffen um den Anwendern (also Ihnen) ein möglichst einfach zu bedienendes System zu bieten ohne dabei auf den Komfort eines Bugtrackers als Entwickler zu verzichten.

Ich danke hiermit für Ihr Verständnis.

Projekt: Icy Tracker

Wie einige vielleicht wissen, gehöre ich zu den Leuten, die hohe Ansprüche an eingesetzte Software, wie zum Beispiel das eingesetzte Web-CMS oder den eingesetzten Bugtracker stellen. Zudem habe ich auch noch sehr genaue Vorstellungen, was ein solches System wie können sollte.

In den letzten Wochen stand ich bei den Überlegungen zu einigen nicht Open Source Projekten vor der Frage, welches Bug-/Issuetracking System dort eingesetzt werden soll. Meine Open Source Projekte supporte ich mit JIRA und an und für sich bin ich mit dem System zufrieden. Doch 8000 Dollar/Jahr für eine „unlimited user“-Lizenz kann und will ich mir beim besten Willen nicht leisten und in der Coding Corner verwenden wir eine Lizenz für Open Source Projekte, die kann ich also nicht mit verwenden.

Nach reichlicher Überlegung und Betrachtung der alternativen Systeme (Mantis, etc) war klar, das ein neues System her muss. Nach kurzer Überlegung habe ich mich für das WCF als Basis entschieden. Der vorläufige Name für das Projekt ist Icy Tracker (info.codingcorner.it). Die Planung werde ich weitestgehend öffentlich über die gerade von mir eingerichtete Dev-Wiki machen und soweit ich Zeit finde gelegentlich hier im Blog kommentieren.

Einen Zeitplan zur Entwicklung des Icy Tracker gibt es nicht und wird es vermutlich auch nicht geben, da sich die Zeit, die ich in das Projekt investieren kann sehr von meiner Arbeit und der Zeit, die ich zur Wartung eines anderen Projektes brauche, abhängig ist.