Re: what needs doing?
I had something similar going (sorry for not answering before)
regarding this to be able to follow translation's status. The tool I used is
derived from the one used by the French translation team coordinator. You
can take a look at the results by going to
http://www.debian.org/international/spanish/coordinacion.
Feel free to take a look at the WWW's CVS and see how this is
implemente (I sent a message to debian-www some time ago explaining how it
went along and what my ideas where for this).
The usefulness of this script is that is a simple Perl script, and
the "database" is a hash array. There's an advantage for this comparing it
to your proposal: mirrors do not need to have PostgresSQL, nor access is
needed to a main database.
However I agree this is a quick fix and I would like it more to have
a scheme as you propose below.
Since I'm trying to finish my Master Thesis and I want to do it
ASAP, I have laid this idea to rest for the next month (until I finish it),
but I would surely like to see this being done (be it my way or anyother).
Enough said about my situation I point out below some details on
your schema:
On Tue, May 23, 2000 at 11:20:18PM +1000, skud@netizen.com.au wrote:
>
> I wouldn't imagine that Wiki was suitable for this. What you really
> need is something more structured, IMHO. For instance, a database which
> contained the following:
>
> Task table
> task_id
> parent_task (zero if top level)
> name
> description
> URL
> urgency (important/normal/wishlist)
> degree of completion
> technical/developer contact(s)
>
> Task/package table (links documentation tasks with packages)
> task_id
> package_name
What's the reason for this table?
Is it to be able to make Debian packages from documents? I would use
a document's table instead. Or do you refer to packages that *need*
documentation?
>
> Documentor table
> documentor_id
> name
> email address
>
> Work table (this shows who's working on what)
> task_id
> documentor_id
I would add a table that would be able to have translations
introduce in the DB, something like:
Translation table (which links original documents with their translated
versions)
document_id
document_id
and you forgot the *documents* table:
Document table
document_id
title
description
CVS
URL
current state (finished, in revision...)
Document and tasks table
document_id
task_id
You should always have *at least* a task 'maintainer' for each document
(unless orphaned)
>
> ... then a bunch of forms and queries to manipulate and view the data.
> This would let us do such things as "What important pieces of
> documentation are not currently being worked on by anyone?" or "who can
> I talk to about this piece of documentation?" or "what documentation
> tasks are outstanding for these packages?"
There some things overlooked from this scheme. Like "which package
provides the X document" (like the dwww database). Please note that there
are currently documentation-only packages in Debian (like the doc-debian
package), which we need to have some way to build "automatically" when a
document gets through an edition/revision/stable process.
>
> I could do a first cut of this in an afternoon in Perl/MySQL. Using
> PostgreSQL (which I'd have to learn first), call it 2 days. I do this
> stuff in my sleep, actually... so if there's some kind of consensus that
> people want it done, let me know and I'll do it.
>
2 days? Maybe building the tables, but doing the forms would take
much more. How about building an entity-relationship model of the database
(with xfig) and sending it here?
Best regards
Javi
Reply to: