On Sep 9, 2006, at 5:10 PM, Borut Bolčina wrote:
What is Community and its content?
Mailing lists, info on how one can participate, how to submit bugs,
some blurb about Apache, etc.
Development and Issue Tracking don't
belong there in my opinion because of their technical natures.
We will try to pick the option that has two different focuses - one
for
newbies and lurkers, the other for users and experts.
The site is also used by Cayenne developers. The is a place where I
go when I want access to SVN, bug tracker, road map, etc. I am a user
too! :-)
Of course we need to hide all this scary backend information from the
regular users, but putting it under its own top-level menu is quite
reasonable I think.
We will try to pick the option that has two different focuses - one
for
newbies and lurkers, the other for users and experts. That is why I
decided
to put shortcuts on the right, but as they are important to users
of Cayenne
framework because they are more frequently accessed, they are more
visually
exposed.
As I said in my other message, what links are important depends on
the user.
* Side menu - maybe each second-level page will have its own small
side menu (if applicable), without duplicating the entire menu on
every page?
The navigation is driven by site content. I don't mean some dynamic
menus
here, just that the volume and data organization decides how the
menu should
look like (multilevel or not, duplicating or not, ...).
+1 - essentially same thing that I was saying.
Here we come to some basic questions we must answer. What
technology we will
decide to use?
I tried to separate the technology discussion from the site structure
discussion, as I wanted to avoid "maven sucks" type of comments in
this thread (oops, I just said it :-)), so let's discuss this in
general terms, and start a different thread if we need to talk
specifics.
Who will host it?
Apache Software Foundation - there are no other options.
Will the site use some server side logic?
There are two parts - static site that will have to be generated
offline and Confluence Wiki. Offline process can have any logic we
want it to have, but the output should be static HTML (possibly with
JavaScript).
Who will take care of it?
Same people who do it today - Cayenne community. I am trying to
figure out some legal issues to allow wider participation (e.g. I
think authorized non-committers should have the ability to submit
content), but I also want to keep this discussion separate from the
navigation design.
How will the content be updated?
That's the sticky question. This is why we have Wiki.
Putting news on the front page is a BIG decision. Using RSS does
not prevent
news being old. [...] Of course it would be great if news section
was on the front page with one
news every week or so, but this won't happen in my opinion.
I agree, but if it can be conditional (no news - no news section.
site generation logic can be smart about that).
I am tutoring my coworker in Cayenne and one of his early remarks
was that
documentation was badly interconnected and structured.
I agree, that's why we are having this discussion.
I mentioned that already by pointing out the Children section.
This is a matter of updating the wiki and maybe creating a better
Wiki template, not with the Wiki itself.
All the documentation should be on main site not on Wiki,
We had main docs checked as XML to SVN before (and we still do for
the few pages on the site). We switched to Wiki for the docs work to
increase participation, and this actually happened (at least
initially after the switch). This is our CMS, and I personally do not
want to go back to the XML files for the book-like "guides". With
Confluence auto-export plugin Wiki content looks no different from
the rest of the static site (provided we create a matching template).
Why do you think Wiki is the problem?
BTW, geronimo project is a good example (they also have all docs on
Wiki). There is a page that points to all documentation resources,
while the resources themselves are Wiki based:
http://geronimo.apache.org/documentation.html
Andrus
