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, [email protected] 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
