Hi, On Tuesday, 2015-07-28 14:53:42 +0200, Florian Effenberger wrote:
> With these changes, I'd like to call the board for a vote on the below item, > so we can proceed and add it to the budget accordingly. Agreeing, +1 Eike > Florian Effenberger wrote on 2015-06-30 at 17:30: > >Hello, > > > >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 == > > > >Grant Proposal: > >Creating a LibreOffice community and developer dashboard ("All about > >LibreOffice") > > > >a cost estimate has been shared with the Board of the Document > >Foundation in private for budget approval and reservation of funds > > > >Grant objective: > >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. > > > >Florian -- GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/ Eike Rathke, Deputy of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, Germany Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: http://www.documentfoundation.org/imprint
pgpZnKqjlQeXX.pgp
Description: PGP signature
