incubator-ctakes-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bleeker, Troy C." <>
Subject First documentation pages
Date Tue, 06 Nov 2012 20:14:49 GMT

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

*         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?

Troy Bleeker * Senior Business Analyst CBAP(r) * Biomedical Statistics and Informatics
Phone: 507-293-1574 * Fax: 507-284-0360 *
Mayo Clinic * 200 First Street SW * Rochester, MN 55905 *

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message