Volunteers are useful, but also breaking the issues down into chunks and
prioritizing the various tasks as well
Tom
On 07/08/14 21:47, Lewis John Mcgibbney wrote:
Next step...
Volunteering to take actions.
Thank you Sean for posting, thisis extremely helpful.
Lewis
On Thu, Aug 7, 2014 at 1:44 PM, <[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
--
Sean Kelly
Vice President, Apache OODT
Member, Apache Software Foundation
--
*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
