Projects:WOSP CMS

Overview

Projekt ma na celu stworzenie w pełni funkcjonalnego systemu zarządzania treścią (ang. CMS) dla potrzeb WOŚP. Podstawowym celem tego systemu jest obsługa serwisów internetowych tzw. "sztabów".

Skala projektu

CMS musi posiadać własny system instalacyjny, na tyle prosty, aby każdy początkujący administrator mógł bez problemu zainstalować go w kilku krokach (jako wzór - patrz Wordpress, Mediawiki). CMS powinien też być w stanie obsługiwać wiele instancji w ramach jednej instalacji - tzw. "centralny serwer", na którym administrator może uruchomić serwis dla potrzeb dużej liczby sztabów i hostować wszystkie instancje w jednym miejscu.

Technologia

Wstępny pomysł to:

• PHP 5
• Mysql 5.0
• Apache 2.x

Główne założenia

• Łatwa instalacja
• Wiele instancji w ramach jednej instalacji
• Skalowalność - wygodna dla sztabu dwuosobowego jak i dla dziesięciotysięcznego
• Dobra dokumentacja
• Moduły:
  • Newsy
  • Kategorie Newsów
  • Strony statyczne (prosty WYSIWYG a'la Wordpress do budowy stron typu Skład sztabu
  • Galeria
  • Możliwość przechowywania plików (Dokumenty itp.)
  • Księga gości
  • Licznik zebranych pieniędzy
  • Komentarze
  • Forum
  • Blog (?)
  • Archiwizacja danych
  • Mechanizm skórek a'la Wordpress - domyślny skin dla każdego roku + opcja modyfikacji z poziomu panelu adm.
  • Emaile?

Czym jest "sztab"

Zakresem działania pojedyńczej instancji serwisu jest tzw. sztab. Sztabem nazywamy grupę osób zorganizowaną na czas pojedyńczego finału, która uzyskała zezwolenie fundacji WOŚP na reprezentowanie interesów fundacji. Sztab organizuje się w okolicach października na jeden finał, po którym rozlicza się z zebranych pieniędzy i dokonuje samorozwiązania. Sztab skupia od dwóch do trzydziestu osób, zazwyczaj bez żadnego doświadczenia informatycznego, które muszą korzystać z serwisu internetowego przy najmniejszym możliwym nakładzie pracy. Sztab nie ma wyłączności na dany rejon i zdarza się, że w jednym mieście funkcjonują dwa lub więcej sztabów.

Przykładowy schemat działania

Sztab zgłasza się do Fundacji WOŚP i w momencie przyznania zezwolenia, administrator Fundacji zakłada nową instancję sztabu, np. "Ełk" na rok "2007" i pojawia się adres sztaby.wosp.org.pl/elk2007 lub coś podobnego . Powinno zostać utworzone jedno konto dla administratora ze strony sztabu, który ma możliwość zarządzania modułami (aktywacja/deaktywacja), modyfikowania listy kont sztabu i ich uprawnień. Tworzy on dodatkowe konta dla swoich współpracowników, dodają oni wstępne treści (informacje o sztabie, plan imprez, otwierają forum, dodają newsy), po czym moderują serwis, dodają zdjęcia itp. a na koniec zamrażają instancje, jest ona archiwizowana i sztab zostaje zamknięty/rozwiązany.

Możliwość wykorzystania gotowych rozwiązań

Na tym etapie planowania, nie istnieją żadne ograniczenia dot. doboru rozwiązań - Drupal, Wordpress, MediaWiki, Joomala itp. Wydaje mi się, że żadne z nich nie spełni tu swojej roli, i wymagałoby wiele pracy, aby je dostosować, ale już wykorzystanie jakiegoś gotowego systemu galerii jest bardzo prawdopodobne.

Licencje

System będzie posiadał otwarte źródła. Wybór licencji zapadnie po zebraniu grupy głównych programistów.

Powody dla, których ten projekt jest ważny

W obecnej sytuacji istnieje ponad XXX sztabów co roku. Każdy z nich (sic!) musi zorganizować sobie hosting, miejsce na serwerze, napisać własny CMS, zarządzać nim i tak dalej. Nie istnieje żadna współpraca między sztabami a fundacją w tym zakresie, skalowalność tego rozwiązania jest absolutnie zerowa, koszty pracy, szczególnia dla małych sztabów przerastają niejednokrotnie ich możliwości, a efektem jest, albo brak witryny, albo ogromna praca wkładana w coś, co mogłoby zajmować dokładnie jedno przyciśnięcie klawisza...

Plan pracy

• Luty 2007 - Skład projektu jest sztywny, podział pracy gotowy, istnieją pierwsze makiety architektury i struktury bazy danych
• Kwiecień 2007 - Projekt wchodzi w fazę alfa. Panel sterowania powinien być funkcjonalny, mechanizm zarzadzania dostepem i kontami rowniez.
• Czerwiec 2007 - Projekt wchodzi w fazę beta. Powinna być funkcjonalna większość modułów, najważniejsze z nich powinny posiadać zamrożone API i być w fazie dokumentacji.
• Sierpień 2007 - System powinien posiadać zamrożone API.
• Wrzesień 2007 - System jest gotowy do instalacji i testowania z pełną funkcjonalnością planowaną na final 2008. Gałąź 1.0. Wydanie 1.0RC.
• Listopad 2007 - System jest po fazie QA, udokumentowany i stabilny. Wersja 1.0 wydana.
• Grudzień/Styczeń 2007 - Aktywne QA, zbieranie feedbacku, analiza statystyczna obciążenia i skalowania systemu, patche do gałęzi 1.0 wyłącznie w zakresie stabilności i wydajności.

Linki

Strony przykładowych sztabów:

• Główno
• Trójmiasto
• PCK w Łodzi
• Szczecin

• Skład zespołu