oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Barber <tom.bar...@meteorite.bi>
Subject Re: OODT Roadmap Telecon: summary of the event
Date Thu, 07 Aug 2014 22:45:03 GMT
Hey guys,

I have documented the stuff in Sean's email:

https://cwiki.apache.org/confluence/display/OODT/OODT+Roadmap+Stories

I've written it as high level user stories that lack in detail. I 
usually follow a format like documented as then detail can be written as

Given:
When:
Then:

Style entries which can be turned easily into Jira and(should we use a 
tool like JBehave) living documentation that proves certain requirements 
are being hit and used.

But! Feel free to change the format if someone has a better suggestion.

Anyway, pad out the wiki pages with details of tasks for each story, 
this could be 1 or 100 sub tasks, which we can then make into jira and 
assign to the willing or unwilling volunteers ;)

Cheers

Tom

On 07/08/14 21:44, kelly@apache.org wrote:
> Folks:
>
> Thanks for dialing into the OODT Roadmap Telecon.
>
> The attendees were:
>
> - Tom Barber, UK business intelligence consultant
> - Roger Carter, JPL intern
> - Cameron Goodale, JPL
> - Michael Joyce, JPL
> - Sean Kelly, consultant
> - Ross Laidlaw, JPL intern
> - Lewis John McGibbney, JPL
> - Tyler Palsulich, JPL intern
> - Rishi Verma, JPL
>
>
> Here are the milestones that I recorded from the telecon, presented in no particular
order:
>
> A. Stability to the codebase.  Tests must pass before we can reliably move forward. 
This is especially troublesome since there are new features we do want to implement, yet our
confidence level of not breaking existing function is low since the tests just don't work.
>
> B. Upgrade OODT's outdated components.  A number of parts within OODT has ossified and
become brittle (XML parsing, for example).  As the (mainly Java) ecosystem has matured, these
components have not, and they continue to be "software hangnails".
>
> C. End-to-end story-driven testing.  While we'd love to see more and more unit testing,
complete integration testing is also vital.  OODT is a large and complex system, and ensuring
all the parts work in a story-driven manner is important.
>
> D. Changing 5 to 10 config files to get OODT just to work is terrible.  And worse, they're
largely XML configuration files.  OODT needs to get-up-and-go out-of-the-box.
>
> E. Documentation and website movement to Apache CMS-based tech.  The static nature of
the OODT website is a barrier to updates.  We'd like for updates to frequent and timely.
>
> F. Make OODT more of a product, less of an architecture.  It's difficult for new users
to approach OODT since it's presented mainly as a software architecture that has some software.
 If we could change it into a product (by providing sensible defaults, IoC, etc.) it could
have a lower barrier of entry.
>
> G. Remove PHP. OODT requires a Java servlet container for its core function, so why bring
in yet another technology for the Balance components?  This increases the exploitable surface
of an OODT server as well as making adoption of OODT trickier.
>
> H. XML specification and/or schema so you can know what can be where.  For these XML
configuration files, the lack of a schema means it's difficult to tell what elements and attributes
go where, which are required, which are optional, etc.  With a schema (and an XML-aware editor)
this becomes easier to do—and gives validation-before-run as a bonus.
>
> I. Where and what are the extension points?  This needs to be clearly documented and
highlighted.
>
> J. Tutorials are static and don't allow for community updates.  We need them on the wiki
instead so everyone can help.  Leave a "getting started" tutorial on the main website, but
move everything else to the Apache Confluence wiki.
>
> K. Put Jenkins build status on the OODT website!
>
> L. Videos (screencasts).  But keep them upbeat.  Edit them carefully so users aren't
watching slow typists backspacing over mistakes repeatedly.
>
> M. Regular release cycle.  Four times a year.  This gives "liveness" to the project,
but also gives confidence to new users knowing that a certain bug or new feature will be addressed
in an upcoming release.
>
> O. Report list subscription numbers in board reports, not # of messages.  This is a more
interesting metric since it demonstrates the breadth of OODT adoption, which is orthogonal
to the amount of discussion which can be dominated by one or two members.
>
> What milestones did I miss?  Do these sound correct?  Please reply to the list and let's
discuss further.  Once we've hammered out this list, we should then priortize them.
>
> Thanks again for your participation,
> --k
>


-- 
*Tom Barber* | Technical Director

meteorite bi
*T:* +44 20 8133 3730
*W:* www.meteorite.bi | *Skype:* meteorite.consulting
*A:* Surrey Technology Centre, Surrey Research Park, Guildford, GU2 7YG, UK

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