On 23/05/2007, at 2:10 PM, Jason van Zyl wrote:
That's what the taxonomy is supposed to be: a hierarchy. But given
that documents were lost in the wiki I put them all on that page so
that I could see them all and try to organize and cull them.
Whatever I saw I quickly tried to categorize. Again this is not the
final form nor is it what's useful by people trying to learn about
Maven. Essentially it should be a hierarchical outline which I'm
modeling in omni outliner. But for the time being as I find bits
and pieces I'm just sticking them on that front page so I can see
them. The hierarchy doesn't exist yet and that's exactly what I'm
trying to make.
Cool, that's what I thought, I just missed that from your description.
How about breaking this down by category first (processes, design
documents, etc), then applying the taxonomy to each under those?
We don't really need links to Jesse and John's IRC discussion on
the front page :)
Our processes are separate from the taxonomy. The taxonomy is just
a hierarchical grouping of information. I just put our process
documents I put there so I could see them. The design documents
would be one of the first derivative documents that link to the
taxonomy. Talking about artifact resolution would link to the
"artifacts and repositories" portion of the taxonomy.
Yep, I think that's what I meant - categorise the design documents by
taxonomy, under a design docs page rather than the home page.
- what content goes in the wiki
In progress documentation. We let stuff sit to long in the wiki and
now we have duplication.
- what goes into an "everybody can write" wiki
In progress documentation by people with no access to the official
wiki.
- what goes as into a doxia generated site.
What we consider final designs and documentation.
I can totally agree with this. I got thrown by your categorising of m
2.0.x design docs, since under this scheme they should be rewritten
and removed from the wiki.
Ad hoc, or in progress collects in the official space with devs
incorporating user space material as deemed fit. As the in progress
documents complete they should get moved/exported to a static site.
Whatever means we decide on.
I think continuously putting them in the site in a clearly delineated
way is a good idea (per the proposal).
Making them final? I think maybe using the confluence doxia parser to
read text files from svn (so it's just a cut/paste/edit rather than a
reformat). Alternatively, a wiki space for "final docs" that is more
tightly controlled (but I personally prefer the docs under SVN for
editing offline and mixing with apt, xdoc, etc)
This is a separate issue. First I would like to deal with the
taxonomy and movement of information from the wikis to the static
site. How the site is actually organized is a process of making
views from the taxonomy.
ok, sounds good.
I think a good chunk of this is done, and if you want to organize
the site according to what you see working I'm fine chiming in as
things form. I'm really not interested in discussing this for the
Nth time with no real results.
ouch :)
I did actually organise the site structure last year. More to do, but
everyone seemed happy with it. It's still a matter of content which
is a bigger deal. But the below is really the next step beyond that
in terms of organisation.
Organize it according to what you have below and we'll try it.
That's a fine approach as far as I'm concerned. I don't think
anyone is going to argue if you're trying to organize the site and
make all the sites standard. That all looks good to me below so now
what's your next thought on actually having that be what we have
for each sub-project?
I'm happy to apply this to a subproject and see how it works. We were
discussing it in Archiva, so maybe there. But I think the best
candidate is SCM. Between the two we cover the two basic types of
subprojects (a framework and an application), so hopefully we can
bounce that around and agree then apply outwards.
Let's run with that below, now what do we do to organize the actual
information for each sub-project and what tools can we make to make
the site making follow that structure below.
I think it's just a matter of configuration at this point. So I'll
get started with SCM. Emmanuel - interested?
I'm also calling on Tim O'Brien and Henri Yandell here since I saw
them at JavaOne and they said they'd help out in some way (even if
just applying patches). I think it was even recorded. Are you guys
in? :)
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
