All,

I'd like to start creating the pages that will become the documentation and the 
starting points. This may be more at once than you'd like to consider but here 
are the changes I see considering who we said before our users are. Don't freak 
out if you see the changes starting. They can always be reverted or changed... 
please comment on any, all, or part of these:


*         Migration from Confluence was harder than anticipated due to 
mis-matched versions. More investigation shows that ASF has installed plug-ins 
to the Apache CMS which make markdown more palatable. Building is yet an 
unknown, at least I have not tried yet.

*         Move Getting Started under GENERAL, so it appeals to everyone who 
first sees the site. It will define our users and point them in the right 
direction.

*         Download should list a fast path to all downloads per release. Like 
we mentioned: the source code, one large JAR, etc. It should be very short and 
point users to full doc elsewhere.

*         Glossary - I already added and populated with the glossary from the 
NIH Confluence wiki.

*         Move Incubator Page, License, and History under COMMUNITY. These are 
less frequently accessed comparatively. Under GENERAL we want the first things 
a new-to-the-site persons considers going to.

*         Community FAQs - not sure there really are any yet. The one that is 
there is covered under the User and Developer sections. Would like to remove 
for now.

*         Add a Developer Guide instead of Source Code. The Downloads page will 
have fast path to code but we need a launching place for all-things-developer.

*         Having Bug Tracker under DEVELOPERS suggests that users should not 
use it. I don't think that's true. Obviously the mailing lists are used if 
possible but if a user knows we have a bug then they can report it. Let's move 
under COMMUNITY.

*         So USERS and DEVELOPERS would have a guide and FAQs, nothing else. 
The guide would have a main summary page followed by links to the top level of 
each release's guide.

Now a question as well. When we went from cTAKES 1.0 to 1.2 we settled on 
calling the parts of cTAKES one can take advantage of "component" as evidenced 
by the diagram created and the documentation section headers, etc. In the past 
month I've seen more people refer to the cTAKES parts as "module". I'm not 
stuck on a name. Perhaps module is more of a maven term and we didn't have that 
before. I have in mind what I like, but as I said it does not really matter to 
me, so long as we are consistent. If we change away from "component" the doc we 
pull over from previous releases will need to be modified, also not too big a 
deal. What do you think?

Thanks
Troy Bleeker * Senior Business Analyst CBAP(r) * Biomedical Statistics and 
Informatics
Phone: 507-293-1574 * Fax: 507-284-0360 * [email protected]
Mayo Clinic * 200 First Street SW * Rochester, MN 55905 * www.mayoclinic.org

Reply via email to