Central teams database (was Re: cvs-po-commits-list *still broken*)

[Christian Rose <menthos gnome org>]

tis 2005-08-09 klockan 21:30 +0200 skrev Danilo Šegan:
> Today at 18:34, Christian Rose wrote:
> > Please don't use the l10n Bugzilla components for that -- since we
> > require teams to have those components, we really shouldn't abuse the
> > component contacts by spamming them with CVS commit mails.
> 
> Isn't it simply better to have an opt-out option (it might even be the
> default)?
> 
> (If I remember the guidelines well, we even suggest using a mailing
> list for Bugzilla component owners, and having these on mailing lists
> is no big deal IMO; of course, having a separate address database is
> ok, but I think we're going to end up with mostly duplicated data)

The idea with the central teams database is that we will end up with
*less* duplication of data than we have today, since that data could be
used for the information on translation status pages and mail aliases or
whatever, without those things having to be extra manual steps that need
to be remembered and done whenever a team needs to be added or updated.

The only thing is that Bugzilla would need to be taught to synchronize
against that information for the l10n components, but then again, we
have fairly competent Bugzilla hackers around, so I suspect that even
that problem is solveable somehow.

My philosophy with the GTP for the last years have been that we should
provide an as low barrier as reasonably possible for translation teams
to contribute GNOME translations. In my opinion, a reasonably low
barrier includes that we should not require teams to have to set up
mailing lists of their own (even though we can recommend them to do so),
nor that we should require them to opt out of excessive information that
they might not even be interested in. Furthermore, things that can be
automated should be automated, so that they will not be additional
manual steps that prevents a new team from getting work done.

These are the manual steps that currently need to be done each time a
new team wants to join, after a "we'd like to start this team for
translation into the Foo language" mail has been sent to this list:

* Look up and confirm that the language actually has a ISO 639 language
code
* Look up and confirm the English spelling of the language name in the
ISO 639 code list
* Add an entry for the team, the proposed coordinator, and the manually
spamprotected mail address of the proposed coordinator to the static
HTML on the teams page
* Ask the coordinator for more information (default owner, default QA
person) so that we can add a Bugzilla component
* Manually add the Bugzilla component
* Ask the coordinator for more information (native language name in
UTF-8) so that we can add the native language name to
http://www.gnome.org/i18n/ when that time comes
* Ask the coordinator whether they have an optional user website to be
put on http://www.gnome.org/i18n/ (those web sites should be aimed
towards users, while web sites listed on the teams page should be aimed
at translators)
* Send an e-mail to Carlos to ask for the English language name to be
mapped against the language code in the translation status pages
(otherwise only the language code will show up on the pages, not the
language name)
* Send a welcome e-mail to the team with basic instructions

While not all of these steps can be automated, many of them seem
redundant, as the information needed to do them should already have been
acquired in an earlier step. Even more so if we decide to add mail
aliases or whatever for teams. Moreover, it seems that much could be won
if the teams database was in a machine parseable format (XML?) that mail
scripts, Bugzilla, the translation status pages, and translation team
web page scripts could automatically extract their needed information
from.

As an example, I have a whole bunch of native language names encoded in
UTF-8 rotting away in my inbox, because there is no place I can
currently put them where they could be useful, generally available and
extracteable by scripts. As a consequence, whenever someone volunteers
to update http://www.gnome.org/i18n/, they must either manually gather
the same information again, or manually ask me to dig out that
information from my inbox, all because we do not have a central teams
database where such information could be put and be accessible.

So I very much fail to see how a central teams database would be
"duplication of data"!? The intent is exactly the opposite, and in any
case, even if we failed with that intent, the situation wouldn't be
worse than the situation with duplicated data that we already have.

What needs to be done is, basically:
1. Come up with a sane DTD for the teams database
2. Migrate the teams data to this DTD
3. Put this XML database in CVS
4. Make sure the web pages use this data through some scripts
5. Make sure the translation status pages use this data
6. Make sure Bugzilla uses this data through some scripts
7. Make sure any other scripts use this data


Christian