Hello,
The Board of Directors at the time of voting consists of 7 seat holders
without deputies. In order to be quorate, the vote needs to have 1/2 of
the Board of Directors members, which gives 4.
A total of 5 Board of Directors members have participated in the vote.
The vote is quorate.
A quorum could be reached with a simple majority of 3 votes.
Result of vote: 5 approvals, 0 neutral, 0 disapprovals.
Decision: The request has been accepted.
This message is to be archived by the BoD members and their deputies.
Florian
Florian Effenberger wrote on 2015-07-28 at 14:53:
Hello,
we have received feedback from Thorsten in his mail at
http://www.mail-archive.com/board-discuss@documentfoundation.org/msg03428.html,
which Björn seems to be fine with.
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.
Thanks,
Florian
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
--
Florian Effenberger, Executive Director (Geschäftsführer)
Tel: +49 30 5557992-50 | IRC: floeff on Freenode
The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE
Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts
Legal details: http://www.documentfoundation.org/imprint
--
To unsubscribe e-mail to: board-discuss+unsubscr...@documentfoundation.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/board-discuss/
All messages sent to this list will be publicly archived and cannot be deleted
