[Anubad] L10n Dashboard

[Sankarshan Mukhopadhyay]

On Fri, Jan 10, 2014 at 4:11 AM, Sayak Sarkar <sayak.bugsmith at gmail.com> wrote:
> Going through all your suggestions the most important thing that came to my
> mind was that I was somehow missing out on the perspective of project
> maintainers / organizations. I guess it's time I started chalking down a
> formal project documentation and come up with an architectural model for
> such a system, before going back to churning out code.

A possible list of users/consumers of your dashboard framework are:

[+] upstream Translation Content Management Systems (T-CMSs) like
Transifex, Pootle, Zanata etc
[+] upstream projects themselves like GNOME, KDE, Fedora etc
[+] Language Team coordinators who would like to do project management
based on real data
[+] Language Team translators who can check how progress is happening
ie. velocity
[+] Language Team reviewers who can cherry pick content to review

Consider for a moment the dashboard of a car. It provides an
at-a-glance state of the system. While it is generally useful to the
passengers, it is mostly useful to the driver and the navigator. In
this case, one has to figure out which kinds of individuals form those
roles. Now, a normal car dashboard provides information about how fast
you are traveling. That is useful information. But, if it were to be
able to tell you how fast you should travel - that is an excellent
piece of data. My analogy is trivial, but I wanted to convey the need
to look at information and present them meaningfully. If a particular
team has been completing a certain number of strings by a specific
number of calendar days, how can one make a prediction about when a
particular release would be complete?

> From what I have gathered so far here are some of the most important
> high-level requirements that I can think of:-
>
>    1. The system should provide a consolidated view for l10n statistics
>    across projects and provide easy access to individual projects.
>    2. The system should be capable of data visualization for real time data
>    gathered from multiple sources, to provide enhanced reporting capabilities.
>    3. The dashboard should be a double ended one: i.e. have separate views
>    for organizations/maintainers and individuals.
>    4. It has to be modularized, so as to separate the view from the
>    back-end stores.
>    5. It needs to easily deploy-able to enable individual teams to directly
>    plug it to their own repositories and use it.

This is extremely important. It should be easy-to-install for anyone
on a reasonably latest release of a distribution that is available on
VPS/PaaS projects.

>    6. The system has to be easily extendable to allow for easy
>    modifications, as well as be light, efficient and user friendly.
>
> I would like to know about your thoughts on these as well as ask if you
> think should be any more added requirements for such a system?
>
> In terms of development speed for the project, I agree that a project of
> this scale needs more aggressive goals with quick iterations, however, at
> the moment there aren't enough contributors to the development efforts for
> the project and most of what is done is primarily by myself during my spare
> time.

I appreciate the fact that you have a basic concept up. This allows
you to make various routes to what can be the end form.


-- 
sankarshan mukhopadhyay
<https://twitter.com/#!/sankarshan>