ASF News Items
==============

The original proposal from Brett was to create a tool that would allow the
board repoting to be made easier for the projects, but I'd like to take
things in a slightly different direction!

I think we should create a system that

  o  gathers project news at a central location for all ASF projects
  o  allows each project to maintain control of it's own information
  o  generates a website (static HTML) with all foundation news
  o  creates a first pass board report from the news items created

The website created would be published as http://news.apache.org/ or some
such URL, and would include feeds and links to the various projects and
other ASF resources. Such a site should have existed years ago and is
really overdue.

Basic Overview
--------------

In keeping with previous efforts and the general ASF philosophy of keeping
data in SVN, I suggest that we store "items" of news in files in an SVN
repository that every project has access to.

Stefano suggested that Atom would be an ideal format to use for the
creation of these files and after reviewing the format 
(http://www.ietf.org/rfc/rfc4287) I think using atom:entry would be a
sensible approach.

In order to create the files I propose we create a "generator" that
committers/pmc's can use to create the files. This would likely be a
command line tool, but web based tools are also possible.

Outputs
-------

Creating the outputs could be done via some simple XSLT stylesheets, allowing
us to seperate the scripting/programming language from the processing
and so making the code more accessible to committers.

Sample File
-----------

<?xml version="1.0" encoding="utf-8"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <id>tag:apace.org,2007-05-22T21-00:Test_Post</id>
  <author>
    <name>david reid</name>
  </author>
  <category term="/General" label="General" />
  <title>Test Post</title>
  <updated>2007-05-22T21:14:00</updated>
  <content>Just a test post.</content>
</entry>


Issues
------

o  We need to arrive at a sensible format for id's that will provide us
   with unique identifiers that are easily created.

   david: Using tag: appears to be the current "best practice", so how
          about
          tag:<project domain>,<date/time>:<title>
          Title would have spaces replaced by underscores.
   david: we should use the first portion of the tag as the filename
          in order to avoid collisions. This is why I think including the
          time is a requirement.

o  What categories should we have?

   david: First pass.
          - general
          - committer
          - pmc changes
          - release

o  Who should be permitted to add entries?

   Committers? PMC members? PMC chairs? ASF members?

o  How do we enforce publishing rights?

   david: I wonder if adding an "Enveloped Signature" created using a PGP
          key and having a list of "trusted" keys in a keyring would be a
          sensible, low overhead solution? Anyone could then add files, but
          only those with a signature created using a key in the keyring
          would be published.
          Of course, people would then need to "apply" to be added, which
          adds administrative overhead!

o  Do we allow entries to have dates in the future?

o  Can we allow entries to be "removed" at a given date/time? Would we ever
   want to do this? How would we add it to the format?

o  What language should we write the command line tool in?

   david: It should probably be a scripting language to allow for rapid
          development and ease of changing direction during development.
          Python seems to have the most traction and would be a new
          challenge for me :-)

o What format should the content take? Should we allow HTML or XHTML?