with our new grant request page online (http://www.documentfoundation.org/grant-request/), we have received the first requests, which - in light of our transparency and openness approach - would like to make public and discuss here.
The second request is about a LibreOffice project dashboard/"All about LibreOffice".
== grant details ==
Creating a LibreOffice community and developer dashboard ("All about
a cost estimate has been shared with the Board of the Document Foundation in private for budget approval and reservation of funds
Create a webpage showing latest activity, summaries and trends of the
LibreOffice project in all areas: development, qa, user-to-user support etc.
The webpage should be easily extensible for developers providing scripts
analysing current and historic data from various project infrastructure.
Grant size: to be tendered
Grant beneficiaries: tender contractor
Grant follow-up: Frameworks, languages and tools used should be popular and widely used to allow the result to be community maintained and sustained after initial development. Extensibility should allow developers to refine the dashboard without deep insight in the used frameworks and tools. Blog posts should advertize the dashboard to the LibreOffice community and invite contributions.
=== User stories ===
As a LibreOffice community member, I want to be able to find out about the latest events and actions happening in the project today presented on a webpage. Updates do not need to be real-time, but delays should not be bigger than 1-2 hours.
As a LibreOffice community member, I want to be able to find out about the latest events and actions happening in the project since my last visit presented as a newsfeed (RSS/Atom) for my reader.
As a LibreOffice community member, I want to be able to create a newsfeed that filters for interest of specific interest for me.
As a LibreOffice community member, I want to be able to query filtered on if an event creates or resolves an action item for a specific subproject. Here are some examples based on Bugzilla: regression filed would be qa-task-created (need confirmation/triage), regression triaged/moved to NEW (qa-task-resolved, dev-task-created), regression fixed (dev-task-resolved).
As a designer, I want to be able to improve layout and looks of the dashboard with just basic knowledge on coding.
As a designer, I want to be able to create subpages that present filtered information of interest to a specific subproject e.g. events and actions of interest for development, of interest for QA etc.
As a programmer, I want to be able to feed events and actions happening on any system of the project to be displayed to the system simply by adding a script generating a RSS/Atom newsfeed to an existing repository using only existing credentials (gerrit account). At least all common *nix script languages (Python, Perl, Ruby, PHO) should be supported, even C/C++/Haskell/Ocaml should be possible unless there are overwhelming troubles.
As a programmer, I want to be able supply summaries and aggregate data by querying for existing events in the system and simply parsing a RSS/Atom newsfeed. I want to be able to send these summaries as an event just like others.
As a programmer, I want to associate events send to the system with tags
because that allows to query for specific types of events either for summaries or for presentation on subproject pages.
As a programmer, I want to be able to publish plain text updates for display in the webpages/feeds.
As a programmer, I want to be able to publish images/charts for display in the webpages/feeds.
As a programmer, I want to be able query for and read the historic data in the system to analyse trends.
As a sysadmin, I want to be able to (re-)deploy the system with SALT only and be provided with whatever (hopefully minimal) documentation is needed for that.
== suggested implementation ==
=== languages, toolkits and frameworks ===
Used code and tools should be open source. For the creation of the frontend (website, feeds) a lean web framework like Django or CodeIgniter should be used to prevent reinventing the wheel. However, the use of a full-blown CMS should be avoided. Both the language and the framework should have a reasonable wide community supporting it (e.g. Top10 at http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html) and more popular that most of the competition at http://www.alternative.to/. The Backend DBMS is recommended to be PostgreSQL as TDF already deploys that.
=== suggested setup ===
This is an example setup to perform the task, improvements/modifications/additions are welcome, if they provide a superior
outlook on reaching the above goals.
=== Website and Feeds ===
Website and Feeds will be delivered by a small application based on a lean web framework presenting the data out of the backend database. The application layer should really be thin -- it should essentially only present the database as as good-looking webpage and well-formed feeds. A cronjob running on this machine will fetch a set of RSS/atom feeds and import them into the database.
=== Developer area ===
The developer area should be a git repository containing scripts (Python/Perl/Ruby/PHP/whatever) generating RSS/Atom-Feeds. These will be triggered to be run in regular intervals (say every 5 minutes) and their output will be published for the database cronjob to pick up. Same for scripts creating images/charts. Ideally, the developer area regularly polls the hosted repository on e.g. gerrit for updates, thus adding new events/actions/summaries to the database (and thus the websites which present a view on the database) should simply be pushing a script to a repo on gerrit.
Additionally there should be an directory that can be read from the scripts, but isnt part of the repository to store auth tokens/credentials for scripts to access their source systems (e.g. bugzilla, askbot, git, etc.) if needed.
I propose to discuss on this list and vote via e-mail; if there's a need for a direct discussion, next weeks board call sounds like the best solution.