Aktualisierungen aller Anwendungen im Wiki

[No_Name]

Bei vielen Projekten in unserem Wiki sind die Anwendungen der verschiedenen Projekte nicht mehr aktuell oder gar nicht erst vorhanden.

Ich würde diese gerne auf den neusten Stand bringen, bin aber bei den wenigsten Projekten aktiv.
Daher bräuchte ich eure Hilfe.

Ich bräuchte von jeder Anwendung folgende Informationen:

- Projekt
- Subprojekt (Falls vorhanden)
- Name der Anwendung mit Version
- Deadline
- Screensaver
- Checkpoints
- RAM-Verbrauch
- Größe des ersten Downloads (Falls bekannt)
- Downloadgröße / WU
- Uploadgröße / WU
- Quorum
- Multithreading bei CPU möglich (Falls ja, was ist die Standardeinstellung und kann man sie in den Projekteinstellungen ändern)
- Ob bestimmte Betriebssysteme bevorzugt werden

Wer mir Arbeit abnehmen möchte, kann seine Angaben im Wiki eintragen oder mit angeben, welches BS mit welcher Hardware (x86 / ARM / GPU) unterstützt wird.
Zudem könnt ihr, nachdem die Anwendung eingepflegt wurde, eure Laufzeiten eintragen.

Das Ganze würde jedem von uns zugutekommen und auch bei Wettbewerben helfen.

Ich werde in diesem Post alle bereits bekannten Projekte / Subprojekte editieren, damit keiner die Arbeit doppelt bzw. umsonst macht.

[lugu]

Genauer wäre es, bei den Laufzeiten auf die entsprechenden WUProp-Einträge zu verlinken, oder?

[No_Name]

Das wäre auch eine Option.

Allerdings würde ich gerne erst einmal bei allen Projekten die Anwendungen auf dem aktuellen Stand haben.
Bei LHC Theory Simulation sind z.B. gar keine Daten vorhanden.

Es würde ja genügen, wenn die aktiven Mitglieder bei ihren aktuellen Projekten einfach einmal die Aufgaben anschauen

[shka]

Im Admin-Kreise hatten wir schon mehrfach Anlauf zu einer Diskussion um Reduzierung/Erweiterung/... der Funktionalität rund um die Projekt-WU-Boxen genommen. Meine Meinung: alles pflegeintensive, kaum aktuell haltbare raus oder anders dargestellt. Reduktion auf das wesentliche, der Rest in eine "Besondere Infos"-Box

Deshalb zu der Aufzählung von dir: (nur meine Meinung)
- Projekt ok, wie bisher
- Subprojekt (Falls vorhanden) ok, wie bisher
- Name der Anwendung mit Version ok, Version grenzwertig (macht wie bspw. bei PG eher in einm Begleittext Sinn), sowas wie MindModelling gar nicht sinnvoll darstellbar
- Deadline vielleicht, oder besondere Info
- Screensaver weg oder Besondere Info
- Checkpoints vielleicht
- RAM-Verbrauch weg oder Besondere Info, betrifft ja ggü. früher nur NFS und die vBoxen
- Größe des ersten Downloads (Falls bekannt) weg oder Besondere Info
- Downloadgröße / WU weg oder Besondere Info (vBox oder früher Burp)
- Uploadgröße / WU weg oder Besondere Info
- Quorum vielleicht, eher besondere Info (WCG-Quorum erläutern)
- Multithreading bei CPU möglich (Falls ja, was ist die Standardeinstellung und kann man sie in den Projekteinstellungen ändern) ja, Icon ergänzen
- Ob bestimmte Betriebssysteme bevorzugt werden vielleicht, eher besondere Info oder gar in Haupttext

[No_Name]

Die Idee finde ich gut, wobei ich die Angabe für Deadline und Checkpoints sinnvoll finde.
Unter "Besondere Infos" fallen dann z.B. der große erste Download bei Rosetta, der RAM-Verbrauch von ECM oder auch den Vorteil von Linux bei Universe?

Bei der Version der Anwendung hatte ich den Gedanken, dass man schnell sehen kann, wie aktuell die Angaben sind.

Edit: Ich vermute, dass ihr erst die Box im Wiki aktualisieren wollt?

[shka]

Nö. Zuerst machst du das Konzept, was überhaupt und wie angzeigt werden soll und dann passen wir schnell daraufhin an.

Aber vielleicht melden sich ja noch ein zwei SGler mit drei vier Ideen zur Weiterentwicklung. Das war ja von mir nur kurz runtergeschrieben. Man könnte genaus noch an die Angaben zum Projekt ran - was macht Sinn?
- Verweise auf Projektteamstatistik bei ... und ...
- Verweis auf Mitgliederwerbung Teambeitritt...
- Verweis evtl. eher auf die Hobbit'schen SG-Projektstats und die Integration der allgemeinen Lage zum Projekt
Einfach die Angaben in den Kästen kritisch prüfen und ein bissel 'spinnen'.

[No_Name]

Dann mache ich auch einen Vorschlag:

- Projekt
- Subprojekt (Falls vorhanden)
- Deadline
- Checkpoints
- Unterstützte CPUs mit BS (Auch ARM mit Linux) und VBox
- Quorum
- Multithreading bei CPU möglich (Falls ja, ob über Projekteinstellungen oder app_config.xml)
- Info-Box mit besonderheiten wie Q1 bei WCG nach 15 erfolgreichen WUs, hoher RAM-Verbrauch, großer Download oder ähnliches.

Die Projektadressen findet man eigentlich auf der HP des Projektes, daher nicht unbedingt erforderlich.
Für Laufzeiten kann man auf WU Prop verweisen. Ist zwar nicht immer ganz korrekt, aber man findet zumindest überall eine Angabe.
Verweiß auf die Statistik von Smeagol und ersetzen der aktuellen Lage im Wiki, da dies bei Smeagol ja schon integriert ist.

[Handicap SG-FC]

- Unterstützte CPUs mit BS (Auch ARM mit Linux) und VBox

hier evtl. noch dazu welches BS bei gleicher Hardware natürlich schneller ist.

LG

[nexiagsi16v]

Da geht ihr aber ganz schön in die Tiefe. Eigentlich gibt es auf jeder Projektseite den Meupunkt "Anwendungen". Da sieht man ja für was das Projekt WUs bereitstellt. Ich würde das nur dahin verlinken, denn deren Admins halten es ja aktuell. Infos wie Deadline oder Quorum sind wirklich nützliche Infos die man nicht sofort auf der Projektseite findet.
Ich würde es wirklich nicht übertreiben, denn sowas aktuell zuhalten ist sehr schwer. Man müßte ja alle 4 Wochen einen Check machen, aber das ist mal völlig albern. Und wenn das nicht auf dem aktuellsten Stand ist, ist der Nutzen ehr gering. Sowas wie Laufzeiten z.b. hängen von zu vielen Variabeln ab, daher weg lassen.

Ich muß ehrlich sagen, wer sowas wissen will, darf sich gern im Forum melden. Ist eh schon enorm was SG hier an Wiki usw. bereit stellt, daher glaube ich geht das hier bissel zuweit, auch wenn es eine gute Idee ist.

[No_Name]

hier evtl. noch dazu welches BS bei gleicher Hardware natürlich schneller ist.

LG

Dafür macht eine Checkbox ja wenig Sinn, das käme dann in die Info-Box

Da geht ihr aber ganz schön in die Tiefe. Eigentlich gibt es auf jeder Projektseite den Meupunkt "Anwendungen". Da sieht man ja für was das Projekt WUs bereitstellt. Ich würde das nur dahin verlinken, denn deren Admins halten es ja aktuell.

Ich fand gerade diese Auflistung anhand der Symbole auf unserer Projektliste sehr hilfreich. Es kommen ja eher selten neue Anwendungen hinzu oder werden entfernt.

[pschoefer]

Aber vielleicht melden sich ja noch ein zwei SGler mit drei vier Ideen zur Weiterentwicklung. Das war ja von mir nur kurz runtergeschrieben. Man könnte genaus noch an die Angaben zum Projekt ran - was macht Sinn?
- Verweise auf Projektteamstatistik bei ... und ...
- Verweis auf Mitgliederwerbung Teambeitritt...
- Verweis evtl. eher auf die Hobbit'schen SG-Projektstats und die Integration der allgemeinen Lage zum Projekt
Einfach die Angaben in den Kästen kritisch prüfen und ein bissel 'spinnen'.

Eigentlich fast schon ein weiteres Thema, aber wenn wir schon dabei sind:

• Ziel, Kategorie, Homepage, Betreiber: in Ordnung
• Status: verbesserungswürdig; hier reicht eine Unterscheidung "aktiv" und "inaktiv/beendet", die Aufteilung in "alpha", "beta" und "produktiv" ist willkürlich und informationsfrei mit Ausnahme der dauerhaften Testprojekte, deren Natur man aber auch im Ziel und im Haupttext klarstellen kann; in der Folge kann auch die entsprechende Spalte in der Projektliste entfallen (Projektvorschlag für Programmierer: ein automatisiertes Ampelsystem basierend auf Server- und WU-Verfügbarkeit)
• Projektadressen: theoretisch über die Projekthomepage zu finden, aber ich halte diese beiden Direktlinks schon für angemessen; nur die Linktexte sind verbesserungswürdig, das Deppenleerzeichen ist mir ein Dorn im Auge
• Team-Statistik: vom Prinzip her in Ordnung, hier sollten wir uns nur einigen, wohin dieser Link führen soll (ich denke, Smeagols Statistiken wären da durchaus der richtige Link), derzeit ist das Wildwuchs und teilweise sind die Links auch tot
• Teambeitritt: in Ordnung; ich wünsche mir, auch in der Projektliste zu jedem Projekt einen SG-Button mit dem hierfür hinterlegten Link zu bekommen, damit man Beitrittsinteressierten einfach sagen kann "klicke in dieser Liste bei all deinen Projekten auf den SG-Button" statt "rufe den Projektartikel zu jedem deiner Projekte auf und finde den Beitrittslink" oder "suche auf der Projektseite nach SETI.Germany und crunche erstmal drei Monate für Seti Germany, bis du merkst, dass du bei einem Fake-Team gelandet bist"
• Teamwerbung: ersatzlos streichen; der "Für XYZ werben"-Link ist dysfunktional (führt auf die Startseite mit der Überblendung "Request unsuccessful: Gone", da das entsprechende Feature schlicht nicht mehr existiert), die Buttons zu den "Sozialen Netzwerken" kann ich zwar mangels dortiger Konten nicht auf Funktion prüfen, glaube aber nicht, dass sie überhaupt genutzt werden
• Forenthread: in Ordnung

Erweiterungswünsche zu den Projektkästen an sich habe ich nicht, aber ich sähe durchaus gern zwei weitere Dinge über die projekte_admin.php verwaltet:

1. account.xml-Datei für den Booster-Account: nicht in den Projektkästen anzeigen, aber daraus eine Tabelle für einen noch zu erstellenden Artikel generieren, welche dann die entsprechenden Links für alle aktiven Projekte anzeigt, ohne dass jemand tote Projekte von Hand entfernen muss

2. aktuelle Lage: auch das gehört meiner Meinung nach nicht in die Projektkästen, aber über dieses System verwaltet statt über einen Vorlagendschungel, bei dem nahezu niemand mal eben alte Projekte entfernen und neue Projekte hinzufügen kann (und wo wir in besseren Zeiten mit mehr Projekten auch schon in ein Limit der Wiki-Software liefen); No_Name hat zwar recht, dass vieles von Smeagols Stats abgedeckt wird, ich halte aber insbesondere die Freitext-Einschätzung der Lage für wertvoll; hier besteht noch Klärungsbedarf wie man das am sinnvollsten mit Smeagols Stats unter einen Hut bekommt


Jetzt aber zu den WU-Kästen:

Dann mache ich auch einen Vorschlag:

- Projekt
- Subprojekt (Falls vorhanden)
- Deadline
- Checkpoints
- Unterstützte CPUs mit BS (Auch ARM mit Linux) und VBox
- Quorum
- Multithreading bei CPU möglich (Falls ja, ob über Projekteinstellungen oder app_config.xml)
- Info-Box mit besonderheiten wie Q1 bei WCG nach 15 erfolgreichen WUs, hoher RAM-Verbrauch, großer Download oder ähnliches.

Diesem Vorschlag stimme ich weitestgehend zu, habe nur folgende Anmerkungen:

• Checkpoints: nicht immer leicht ermittelbar, deshalb würde ich mir hierzu wünschen, dass "vorhanden" oder auch "nicht vorhanden" ausgewählt werden kann, sodass man sehen kann, ob ein Projekt wirklich keine Checkpoints hat oder nur niemand sich das so genau angesehen hat
• unterstützte Systeme: siehe unten
• Multithreading: das gehört meiner Meinung nach in das Freitextfeld, weil eben immer ein Kommentar erforderlich ist, wie die Standardeinstellung ist und auf welchem Wege man das ändern kann; eine Checkbox wäre nur sinnvoll, wenn man automatisch eine Liste der Projekte mit Multithread-Unterstützung generieren wollte, allerdings bin halte ich das für umso sinnloser, je mehr ich darüber nachdenke (nützlich wäre das ja nur für jemanden, der gezielt Projekte mit Multithread-Unterstützung sucht, üblicherweise taucht aber immer nur die Frage auf, ob Projekt XYZ Multithreading unterstützt, welche aber eben schon der jeweilige Projektartikel im Freitextfeld beantworten würde); sollte ich in diesem Fall den Bedarf falsch einschätzen, wäre ein optionales Feld sinnvoll; entweder werden Informationen hinterlegt, wie das Multithreading abläuft, oder aber dieser Punkt wird gar nicht angezeigt (das wäre auch eine Idee für das Hinterlegen optimierter Anwendungen)

Für Laufzeiten kann man auf WU Prop verweisen. Ist zwar nicht immer ganz korrekt, aber man findet zumindest überall eine Angabe.

Die Frage ist, inwieweit man damit auf ein totes Pferd aufsteigt, aber der Status Quo (jeder kann einen Laufzeit-Hardware-Datenpunkt eintragen) hat sich definitiv nicht bewährt (praktisch niemand nutzt diese Möglichkeit und die wenigen so hinterlegten Daten sind zumeist veraltet und können nicht einmal leicht gelöscht werden, was zu solchen Blüten wie den Angaben im Artikel zu WUProp führt). Deshalb bin auch ich dafür, hier stattdessen ein Feld für einen passenden Link zu WUProp vorzusehen.

Da geht ihr aber ganz schön in die Tiefe. Eigentlich gibt es auf jeder Projektseite den Meupunkt "Anwendungen". Da sieht man ja für was das Projekt WUs bereitstellt. Ich würde das nur dahin verlinken, denn deren Admins halten es ja aktuell.

Eigentlich keine schlechte Idee, ich sehe aber zwei Probleme: Erstens könnten wir unsere Projekte nicht mehr nach Betriebssystem- oder GPU-Unterstützung filtern, wenn wir dazu keine Informationen mehr in unserer Datenbank haben. Zumindest Fragen wie "Ich habe eine AMD-Grafikkarte, welche Projekte laufen darauf?" gibt es aber schon gelegentlich, sodass dieses Feature recht nützlich ist (auch wenn die aktuelle Umsetzung über Kategorien verbesserungswürdig ist). Nun stellen die Projekte die von dir genannte Anwendungsübersicht auch in einem maschinenfreundlichen Format zur Verfügung (Ausnahme ist -wie könnte es anders sein- WCG ), sodass man theoretisch sogar automatisiert diese Informationen in unsere Datenbank importieren könnte. Aber dann ist da noch mein zweiter Einwand: Insbesondere für weniger erfahrene Benutzer bleibt bei der Anwendungsübersicht oft unklar, welche Anwendung für welche GPU verfügbar ist, da die plan_class-Namen, die in Klammern hinter der Versionsnummer genannt werden, nicht genormt sind. Das würde dann auch das automatisierte Auslesen erschweren. Daher halte ich den manuellen Aufwand in diesem Fall für gerechtfertigt, zumal es auch gar nicht so viele Änderungen gibt und meistens auch in den Projektnachrichten vermeldet wird, wenn Betriebssysteme/GPUs neu oder nicht mehr unterstützt werden.

Allerdings habe ich einen Verbesserungsvorschlag dazu: Derzeit kann man nicht klar angeben, wenn beispielsweise eine Anwendung für Windows, Linux und macOS auf CPU, aber nur für Windows auf GPU angeboten wird. Da könnte man nun munter noch weitere Icons mit immer schlechterer Erkennbarkeit generieren, wie sie auch für bisher fehlende Plattformen wie Linux auf ARM oder vbox gestaltet werden müssten, ich würde das ganze aber lieber zweidimensional als Tabelle gestalten, mit den Betriebssystemen (Windows 32 Bit, Windows 64 Bit, Linux 32 Bit, Linux 64 Bit, macOS 32 Bit, macOS 64 Bit, Android, andere) als Spaltenüberschriften und den Ressourcen (x86-CPU, ARM-CPU, NVIDIA-GPU, AMD-GPU, Intel-GPU, vbox, andere) als Zeilenüberschriften, die natürlich wieder durch die entsprechenden Icons dargestellt werden könnten (wobei zumindest die Windows- und das AMD-GPU-Icon eine Aktualisierung gebrauchen könnten). Die Exoten FreeBSD, Solaris, macOS auf PowerPC und Linux auf PS3, die aktuell noch explizit ausgewählt werden können, werden äußerst selten unterstützt und vermutlich auch nicht viel häufiger benutzt, sodass ich sie unter "andere" zusammenfassen und nur im Freitextfeld näher ausführen würde.

Natürlich lässt sich diese Tabellendarstellung dann nicht mehr so einfach für die Projektliste oder die Kategorien übernehmen, sodass ich hierzu gleich auch noch einen Lösungsvorschlag gebe: Weg mit diesen Kategorien und der Spalte "Anwendung vorhanden für" in der Projektliste, stattdessen die Projektliste filterbar machen, sodass man oberhalb der Projektliste dann z.B. "Windows 32 Bit" und "NVIDIA-GPU" anklicken kann und dann nur Projekte angezeigt werden, die eben eine Win32-Anwendung für NVIDIA-GPU haben.

[No_Name]

Ist das ganze denn soweit mit unserem Wiki umsetzbar?

[shka]

Du gibst vor, was wo wie das Wiki machen soll - und das macht das dann auch... irgendwann ... nach guten Zureden.

Ich ernenne dich hiermit zum "Aktualisierung-aller-Anwendungen-im-Wiki"-Beauftragten (AaAiW).

Du filterst die Ideen hier und machst Schritt für Schritt Vorgaben, was im Wiki geändert werden soll.
Dabei gibt es 4(5) Komponenten, die sich gegenseitig beeinflussen und beachtet werden müssen:
- die Datenbank (die muss dich nicht interessieren)
- die Darstellung in der Projektgesamtübersicht
- die Darstellung im Kasten auf der Projektseite
- die Pflegeseiten zu den Angaben
- (optional) die Integration der allgemeinen Lage in die DB und Pflegefrontends (unabhängig, wo die die Daten dann dargestellt werden)

[pschoefer]

Noch zwei Vorschläge, die der Ai Weiwei, ääh, AaAiW bedenken möge:

• WU-Kästen sollten nicht angezeigt werden, wenn ein Projekt auf inaktiv/beendet gesetzt ist (Beispiel: Riesel Sieve, die Informationen im WU-Kasten sind nicht mehr relevant, der Artikel ist daher doppelt so lang wie nötig)
• ebenfalls fehlt eine Möglichkeit, Subprojekte auf inaktiv zu setzen (diese sollten dann ebenfalls nicht mehr unter dem entsprechenden Projektinfo-Kasten angezeigt werden); die Alternative wäre löschen, aber manchmal werden Subprojekte ja auch reanimiert

[No_Name]

Ok, dann versuche ich mich mal als AaAiW (Erstaunlich, wie schnell man hier einen Posten bekommt):

Projektkasten:

Projektname mit Logo darunter (wie bisher)
Ziel des Projektes (wie bisher)
Kategorie (wie bisher)
Homepage des Projektes (wie bisher)
Status (lediglich "aktiv" oder "inaktiv/beendet" zum auswählen)

Projektadressen:

Serverstatus (wie bisher Direktlink)
Forum (wie bisher Direktlink)
Wo auch immer dieses "Deppenleerzeichen" ist, sollte das nicht mehr erforderlich sein.

Team-Kasten SETI.Germany:

Team-Statistik (Link zu der jeweiligen Projektstatistik son XSmeagolX)
Teambeitritt (Immer ein direkter Link zum Teambeitritt) Hier PG als Beispiel http://www.primegrid.com/team_join_form.php?id=11
Forenthread (Wie bisher Link zum jeweiligen Thread in unserem Forum)
SG-Booster Link zum Download der account.xml-Datei für den Booster-Account
Aktuelle Lage Link zu unserer aktuellen Lagen, soweit diese bleibt. Vorerst gestrichen.

Workunits:

Projekt bzw. Subprojekt (Wie bisher)
Deadline (Wie bisher)
Laufzeit (Link zum Projekt bei WU Prop) Hier PG mit 321 LLR als Beispiel: http://wuprop.boinc-af.org/results/p...=321+%28LLR%29
Checkpoints (Zum Auswählen: Vorhanden / Nicht vorhanden / Unbekannt) oder nur anzeigen lassen, wenn etwas ausgewählt wurde
Quorum
Unterstützte Systeme als Tabelle mit Kopfzeile :Windows 32 Bit, Windows 64 Bit, Linux 32 Bit, Linux 64 Bit, macOS 32 Bit, macOS 64 Bit, Android, Weitere
und als Spalte (x86-CPU, ARM-CPU, NVIDIA-GPU, AMD-GPU, Intel-GPU, vbox, Weitere) zur Auswahl
Textfeld für Besonderheiten wie: Multithread mit Erklärungen, Quorum Erklärung bei WCG, großer Download, besondere unterstützte Systeme und/oder zu bevorzugendes BS etc.


Dann wäre es sinnvoll, wie von pschoefer beschrieben, in der Projektliste die unterstützten Anwendungen aus der Liste zu nehmen und stattdessen eine Art Dropdown-Menü mit Mehrfachauswahl zu nutzen.
Sobald auf eines der Subprojekte die Auswahl passt, sollte das Projekt angezeigt werden.

Über die genaue Umsatzung der aktuellen Lage müsste man sich dann gemeinsam mit XSmeagolX Gedanken machen.


Ich hoffe ich habe nichts vergessen und warte auf weitere Vorschläge bzw. Kritik.

[shka]

Welcher Teil von

Du filterst die Ideen hier und machst Schritt für Schritt Vorgaben, was im Wiki geändert werden soll.

war unverständlich?

Dann such ich mir die ersten Schritte mal selbst raus.

[No_Name]

Welcher Teil von

war unverständlich?

Dann such ich mir die ersten Schritte mal selbst raus.

Wie am Ende meines Beitrags geschrieben, wollte ich nur sicher gehen, dass jeder die Möglichkeit hat, sich alles einmal anzuschauen und eventuelle Ideen noch einzubringen, bevor das ganze umgesetzt wird. Außerdem hätte ich auch auch etwas vergessen können.

[shka]

Sodele, habe mal angefangen:
- bissel DB-Bereinigung
- Projektstati auf 2 beschränkt
- Social Media raus (zumindest in der bisherigen Form)
- WU-Anzeige für inaktiv unterbunden

Bei inaktiv ebenfalls ausblenden:
- Homepage? m.E. nein
- Serverstatus? m.E. ja
- Forum? m.E. ja
- Team-Statistik? m.E. ja (zumindest Link auf Hobbit-Stats)
- Teambeitritt? m.E. ja
- Forenthread? m.E. nein

[No_Name]

Sehe ich genau so.

Falls diese beiden Vorschläge auch umgesetzt werden:

Den Link zum Booster würde ich mit ausblenden.
Den Link zur aktuellen Lage würde ich lassen, denn dort stehen dann ja zum Teil Erklärungen über den genauen Status des Projektes drin. Vorerst gestrichen

[pschoefer]

Den Link zur aktuellen Lage würde ich lassen, denn dort stehen dann ja zum Teil Erklärungen über den genauen Status des Projektes drin.

Für einen Link sehe ich eigentlich keinen Bedarf, da sollten wir besser in einem späteren Schritt nachdenken, wie wir die aktuelle Lage mit Smeagols Stats verheiraten können. Wichtiger wäre, dass auch die Erklärungstexte für die aktuelle Lage über die projekte_admin.php geflegt werden (ohne dass sie dann im Projektkasten angezeigt werden), damit eben auch die aktuelle Lage aus der Datenbank generiert werden kann und keine weitere Projektliste gepflegt werden muss.

Und wo ich gerade bei weiteren Projektlisten bin, ist mir noch diese Liste auf den Schirm gekommen, bei der offenbar auch das letzte Mal jemand tote Projekte entfernt hat, als noch Dinosaurier die Erde bevölkerten. Daher würde ich gern auch noch den Founder auf der projekte_admin.php hinterlegt (ebenfalls nicht im Projektkasten anzuzeigen) und diese Liste für aktive Projekte automatisch erzeugt sehen.