Differences between revisions 3 and 16 (spanning 13 versions)
Revision 3 as of 2006-07-17 22:12:29
Size: 1262
Editor: ?aba
Comment:
Revision 16 as of 2009-03-27 07:31:14
Size: 6056
Editor: BenFinney
Comment: one pseudo-header per message, which contains multiple fields
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from DebianTimes
Line 3: Line 4:
It is related to something like dot.kde.org, and should contain all the nice small items that are too unimportant for debian-news@lists.debian.org, but still are important enough that we should like to speak about it. One of the key items is that more people should have the right to add articles there. It is related to something like dot.kde.org, and should contain all the nice small items that are too unimportant for debian-news@lists.debian.org, but are important enough that we should announce them somewhere. One of the key items is that more people should have the right to add articles there.
Line 5: Line 6:
All on this page is just a first draft, feel free to change it. This page is still in draft stage.
Line 9: Line 10:
From the user's point of view, it is basically "just another rss page". Articles on DebianTimes should be categorized, and users can decide which categories they want to see.
From the user's point of view, it is basically "just another html/rss page". Articles on DebianTimes should be categorized, and users can decide which categories they want to see.

For the "end users" there are two "simple" interfaces: A rss-style one (or
rather many - there is more than one standard), and a normal html-style one.

For the html-front end, users should see the "current" 10 (configurable per user) articles on
the front page, and be able to scroll back in history to older months.

The rss-style page includes the most recent 30 entries.

Both the html pages and the rss feeds should be "configureable" for the end users to decide which categories they want to see and which not.

Articles are shown as http://times.debian.net/123-etch-relased.html
(but this is just a sample now, nothing behind it :) ), but
the server ignores anything after the first -, so that users see what the
article is about without forcing complex article handling on the server
side.

[Q: Syntax for categories? Only "all but not marked this and that" and "none
but only marked so and so"? Or more (complex)?]
Line 14: Line 35:
  * news   * news [should the "normal" news be syndicated and be put in a different category?]
Line 16: Line 37:
  * events announcements
  * event-reports
  * event-announce
  * event-report
Line 27: Line 48:
= Backend =
Line 29: Line 49:
[not decided yet] = Submitter =

Articles can be submitted via two ways: Per signed mail, and by an
http-interface. This allows the submitter to work the way (s)he prefers to
work, and the server to numerate the articles.

Articles contain meta-information via fields in the pseudo-header of the message.
These fields include {{{Tags}}}, {{{Subject}}}, {{{Short Subject}}} (for the article
name), {{{Language}}} and, if appropriate, publication date; articles not
containing a publication date are published right now.

The body itself is written in some wiki-style enriched text [FIXME: which
one?].
  * http://en.wikipedia.org/wiki/Textile_(markup_language)
  * MoinMoin-style (like this wiki)
Line 32: Line 66:
Some nice items for the backend (might?) include:
  * needs to be driven from svn/... for regular updates
  * import rss from other sides, like dwn, security?
= Translation =

(Translation will probably be added after the first prototoype.)

 * There are files for the different languages, each language in a directory (rationale: you don't need to checkout all)
 * Any commit is sent out by mail to the people who want it, a list per language (same rationale)
 * The translations are marked which version of the original file they reflect; so, it's relativly easy to see where to work on.
 * The published-date of the different translations is the same by default, but can be overwritten.
 * Usually commits for the original language should be done "in time" relative to the publication-date so that the translators have enough time to follow up; by default, an article is published 36 hours after submission (though 36 hours shouldn't be expected to be enough in all cases). Also, translators could mark their translation "not yet done"
 * The translators interface would be, in free choice for the translator, be via mail, rcs (e.g. svn) and web.
 * In cases of syndicated articles, translation (if existend) is automatically syndicated as well.

= Website Backend =

The rcs checkout is updated. A (fast) index of important stuff exists.
A "last changed"-time for all articles is put somewhere on the file system.

The articles are put by the system in some rcs (svn?), translation is put
in the same file in the other languages directory.
Fixes to the article can also be commited via the rcs-interface.

Any article has two dates: The semantically date, taken from the {{{Date}}} field
and put on the website, pubDate etc, and the technically date, taken from
last checkin and put into lastBuildDate.
If the article changes content, update the semantical date as well; otherwise
(e.g. spelling corrections), don't change it.
Also, the article has a guid of http://times.d.n/$lang/$id, so that it stays the same even if the short title changes.

Any changes to an article are sent out by mails to the submitters/translators/admins.

When a client requests some page (i.e. a special combination of tags),
it is looked up whether this combination is already cached and at least
as current as the last change. If so -> deliver.

Otherwise, the page is created by parsing the index and - if required - the
relevant articles. Code from planet.debian can be take to do this without
too much effort. The page is stored, and, if there are too many stored
pages (remember, with 10 categories we can have 3^10 pages, or 22 (or so, depending on
which combinations we allow), which might be really many different pages), some
old non-standard ones are removed (non-standard means: not with all tags
enabled, and probably something like "everything except dwn").

The index should contain information about name of the article, date, tags,
url, so that it's enough to generate overview pages.


= Layout =

Perhaps something looking a bit like ... a Newspaper? With a logo of this old style looking letters? Or whatever seems like a good idea.

What we need is
  * an index page with the current articles
  * monthly pages of the history
  * per-article pages

Each article has one or more categories; also for the overview pages, it is possible to select only certain categories.

This page is about times.debian.net - currently a service in preparation.

It is related to something like dot.kde.org, and should contain all the nice small items that are too unimportant for debian-news@lists.debian.org, but are important enough that we should announce them somewhere. One of the key items is that more people should have the right to add articles there.

This page is still in draft stage.

User Interface

From the user's point of view, it is basically "just another html/rss page". Articles on ?DebianTimes should be categorized, and users can decide which categories they want to see.

For the "end users" there are two "simple" interfaces: A rss-style one (or rather many - there is more than one standard), and a normal html-style one.

For the html-front end, users should see the "current" 10 (configurable per user) articles on the front page, and be able to scroll back in history to older months.

The rss-style page includes the most recent 30 entries.

Both the html pages and the rss feeds should be "configureable" for the end users to decide which categories they want to see and which not.

Articles are shown as http://times.debian.net/123-etch-relased.html (but this is just a sample now, nothing behind it :) ), but the server ignores anything after the first -, so that users see what the article is about without forcing complex article handling on the server side.

[Q: Syntax for categories? Only "all but not marked this and that" and "none but only marked so and so"? Or more (complex)?]

Categories

  • weekly-news (via rss-syndication)
  • news [should the "normal" news be syndicated and be put in a different category?]
  • security-announce (via rss-syndication)
  • event-announce
  • event-report
  • success-stories
  • derivatives
  • release-related
  • regional categories: europe, america, asia, [what for .au+.nz?] [split ca/us vs latin-america?]

[add some more?]

[any reasonable ones via rss-syndication, like people-behind-debian]

Submitter

Articles can be submitted via two ways: Per signed mail, and by an http-interface. This allows the submitter to work the way (s)he prefers to work, and the server to numerate the articles.

Articles contain meta-information via fields in the pseudo-header of the message. These fields include Tags, Subject, Short Subject (for the article name), Language and, if appropriate, publication date; articles not containing a publication date are published right now.

The body itself is written in some wiki-style enriched text [FIXME: which one?].

Translation

(Translation will probably be added after the first prototoype.)

  • There are files for the different languages, each language in a directory (rationale: you don't need to checkout all)
  • Any commit is sent out by mail to the people who want it, a list per language (same rationale)
  • The translations are marked which version of the original file they reflect; so, it's relativly easy to see where to work on.
  • The published-date of the different translations is the same by default, but can be overwritten.
  • Usually commits for the original language should be done "in time" relative to the publication-date so that the translators have enough time to follow up; by default, an article is published 36 hours after submission (though 36 hours shouldn't be expected to be enough in all cases). Also, translators could mark their translation "not yet done"
  • The translators interface would be, in free choice for the translator, be via mail, rcs (e.g. svn) and web.
  • In cases of syndicated articles, translation (if existend) is automatically syndicated as well.

Website Backend

The rcs checkout is updated. A (fast) index of important stuff exists. A "last changed"-time for all articles is put somewhere on the file system.

The articles are put by the system in some rcs (svn?), translation is put in the same file in the other languages directory. Fixes to the article can also be commited via the rcs-interface.

Any article has two dates: The semantically date, taken from the Date field and put on the website, pubDate etc, and the technically date, taken from last checkin and put into lastBuildDate. If the article changes content, update the semantical date as well; otherwise (e.g. spelling corrections), don't change it. Also, the article has a guid of http://times.d.n/$lang/$id, so that it stays the same even if the short title changes.

Any changes to an article are sent out by mails to the submitters/translators/admins.

When a client requests some page (i.e. a special combination of tags), it is looked up whether this combination is already cached and at least as current as the last change. If so -> deliver.

Otherwise, the page is created by parsing the index and - if required - the relevant articles. Code from planet.debian can be take to do this without too much effort. The page is stored, and, if there are too many stored pages (remember, with 10 categories we can have 3^10 pages, or 22 (or so, depending on which combinations we allow), which might be really many different pages), some old non-standard ones are removed (non-standard means: not with all tags enabled, and probably something like "everything except dwn").

The index should contain information about name of the article, date, tags, url, so that it's enough to generate overview pages.

Layout

Perhaps something looking a bit like ... a Newspaper? With a logo of this old style looking letters? Or whatever seems like a good idea.

What we need is

  • an index page with the current articles
  • monthly pages of the history
  • per-article pages

Each article has one or more categories; also for the overview pages, it is possible to select only certain categories.