[OOTB-hive] [ADDONS][ALL] Moving projects into the Order of the Bee
Axel Faust
axel.faust.g at googlemail.com
Sun Oct 23 20:28:34 BST 2016
Hello,
as some of you know Markus Joos and myself have started a project to
"liberate" the Alfresco Support Tools to be used with the Alfresco
Community Edition and even improve / add some tools as the community may
see fit. The project is currently hosted in my GitHub repository (
https://github.com/AFaust/ootbee-support-tools), but as you can see from
the naming, description and project coordinates (Maven group ID) I always
intended this as a project that could be owned and maintained by the Order
in the long run, moving it into the OOTBee GitHub organisation. Since we
have not yet considered such a request / case in detail, I would like to
start the discussion with this project as a reference.
The following is a suggestion of aspects we should think about and
determine / agree on so there is proper support for owning / managing any
projects and we (OOTBee) don't end up being swamped or diluting the purpose
of this option. The suggestions are not meant to be exhaustive and I highly
appreciate any additional input.
Why / when should projects be (allowed to be) moved into / owned by OOTBee?
- Full ownership
- Common / generic use case applicable to a majority of users /
community members
- Community ownership (vs single benevolent dictator) can help
feature evolution / up-to-date-ness, or ensure availability
without relying
on long-term priorities of original developer
- Purpose is close to the OOTBee mission (promote Community Edition /
showcase and strengthen suitability for use in production)
- Scope / complexity is "manageable" by OOTBee organisation
- Temporary ownership (trusteeship / "orphanage")
- Significant user / installation base or significant "value" for
community / OOTBee mission
- Must have had production release(s) and (standard) Open Source
license
- Project (virtually) abandoned or about to be
- Either request for OOTBee to help find successor from within
community or committee / sub-group initiative
- Either compatible to a recent major release (i.e. max 2 or 3
releases ago. e.g. at least 4.2.f now) or "manageable" scope / complexity
- A minimum number or majority of members of the Order or a committee /
sub-group supports the proposal to move a project into OOTBee
- At least one member commits to being responsible for necessary
preparation and transfer tasks
- A minimum number of members or a committee / sub-group commits to
being responsible for long-term maintenance, management or trusteeship tasks
What could a potential "process" look like?
1. (External, optional) request from community / developer (about to
abandon a project)
2. (Initiator) Proposal announced via mailing list w/ request for
supporters & commitments
3. (Initiator) Proposal put to vote backed by task plan and
responsibilities
4. (Members committed for prep + transfer) Perform preparatory tasks in
a "staging" repository (member / ext. organisation)
5. Review & transfer into OOTBee
6. (Members committed for long-term) manage project / recruit successor
maintainer from within community
- (Trusteeship) if successor maintainer is not found in X months,
properly archive project and update any listings / documentation accessible
to OOTBee
- (Full ownership) if no activity occurs in project in X months, review
purpose & state of addon + review member commitment (archive / close
project as necessary)
- Report to OOTBee board (regular intervals, likely via single
designated board member)
What may other requirements (need to) be? (initial or for prepraratory
tasks)
- Full ownership
- Must use orderofthebee.org (or similar) as base namespace /
identifying coordinate
- Must comply with OOTBee best practice criteria prior to move, e.g.
ADDONS review criteria (w/ necessary exceptions for "virgin"
projects, i.e.
listing or release existence)
- Must make use of OOTBee build + distribution infrastructure
services (unless incompatible)
- Must have defined feature roadmap and maintenance/support
responsibilities (i.e. regular issues and PR review) incl.
fallback contact
options
- Must be compatible with a recent major GA release
TL;DR
"Moving a project into OOTBee" will not occur unless members commit to the
idea and process sufficient preparatory tasks even before the move. If
ownership / trusteeship is not working, OOTBee board may ultimately trigger
archival ("kill") of a project.
Regards
Axel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.xtreamlab.net/pipermail/ootb-hive/attachments/20161023/38a60fa1/attachment.html>
More information about the OOTB-hive
mailing list