As we're planning to start quite a lot of work shortly in a sandbox, but with
the intend to later merge this into the 'mainstream' Rave life-cycle, I think
this is a good moment to further discuss how to track and manage sandbox
projects from a (P)PMC perspective.
Right now we have two sandbox 'projects': rave-extensions (with 2 sub modules)
and science-gateways (with 4 sub modules).
So far, some (but definitely not all) activities in these sandboxes have been
recorded in JIRA, but with no tracking/marking of any status, version(s) or
related components. IMO this is not preferred as it kind of 'pollutes' JIRA and
makes it more difficult to assess the status of these sandbox projects.
I think we can improve on this and that the (P)PMC should take more
responsibility or at least oversight on the ongoing work in these sandboxes.
First of all, IMO these sandbox projects should have a specific goal and
intended lifespan. As being part of our SVN tree, the PMC is formally
responsible of its content and its relevance to the project and an open-ended or
indefinite scope isn't really meaningful.
As a minimum we can at least track the ongoing work in JIRA and label it
appropriately.
One way we might do this is using of the JIRA 'Component' classification.
My proposal is to define a separate Component for each sandbox (module) and
include a sandbox- prefix to separate them from 'endorsed' components, like:
sandbox-extension-sso
sandbox-vanilla-extension
sandbox-science-gateways-gadgets
sandbox-science-gateways-gridship-extensions
...
Furthermore, we can mark the non-versionable characteristic of these sandbox
components and thereby also prevent end up with endless un-versioned issues.
As JIRA versions are plain strings, we can simply introduce a 'sandbox' version
and use that for all JIRA issues concerning these sandbox projects.
One 'sandbox' version should suffice IMO as there shouldn't be sandbox
'releases' anyway.
And maybe we should even use this 'sandbox' version for artifacts within the
sandbox, e.g. rave-vanilla-extension-sandbox-SNAPSHOT instead of
rave-vanilla-extension-0.10-SNAPSHOT. That'll make it very clear sandbox
projects are not endorsed nor life-cycle managed.
Once a sandbox project becomes really useful this will also help 'drive' it out
of the sandbox, just to get rid of the annoying 'sandbox' label ;)
And if a sandbox project doesn't build up traction, gets too far out-of-sync
with or behind the main project, or its testing/exploration purpose has been
fulfilled, sandbox projects probably should either be 'retired' (moved to a rave
'attic' svn folder?) or else simply deleted.
I definitely don't like sandbox projects (like I do see in other TLP projects)
which are abandoned and left to 'rot'.
Assuming lazy consensus on the JIRA part of this proposal as it is easily
revertible at any rate, I'll add to JIRA a 'sandbox' version and new 'sandbox-'
prefixed components for the new content services proposal. And if there is
general agreement on this, we should do the same for the other sandbox projects.
WDYT?
Ate
