oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Bennett <lmzxq....@gmail.com>
Subject Re: OODT Documentation Organisation
Date Mon, 15 Jul 2013 18:35:55 GMT
Hey Tom,

+1 from me. I'm keen to change it.

Cheers,
Tom


On 12 July 2013 22:18, Tom Barber <tom.barber@meteorite.bi> wrote:

> Hi guys
>
> Whilst working on getting to know OODT better I walked through the CAS
> Curation tutorial on the website and found it both hard to read and buggy
> in places. I also (as a newbie) found getting started and tutorial stuff
> tricky to locate with bits being on the main website and some on the wiki.
> I guess this is left over from the Apache ingestion.
>
> I took the liberty of migrating the original Curation tutorial over to the
> wiki and made a few tweaks although I would like to improve this further
> over the next week or so:
> https://cwiki.apache.org/**confluence/display/OODT/**
> Deploying+and+using+CAS+**Curator<https://cwiki.apache.org/confluence/display/OODT/Deploying+and+using+CAS+Curator>
>
> My question is really this, is there a documentation policy with regards
> to creating stuff and guiding new users. Personally I feel that as much of
> the documentation as possible should be moved across to the wiki to allow
> users to develop and maintain it as OODT grows and changes (and allows
> people to fix errors). Also finding the wiki isn't very obvious from the
> main OODT website, I would suggest that whoever maintains the website puts
> the wiki link into the header or something allowing people easy access to
> it, otherwise its buried in various page menus.
>
> Having worked closely with a number of open source tools over the years,
> especially as a newbie, I find the wiki documentation invaluable in getting
> started and guiding new users, if no one has any objections I'd like to put
> some time and effort into organising the wiki and landing pages on their in
> a way that helps guide people in a more effective manner. This will clearly
> be extended as I learn more myself :)
>
> Cheers
>
> Tom
>

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