[OOTB-hive] WG: [ADDONS] Proposed activity details

Tue Aug 19 23:48:54 BST 2014

Hello guys,

I’d like to get the ball rolling in the area of “Order-endorsed add-ons” / the “honeycomb of free add-ons” as I see it as somewhat of a pre-requisite to the “OOTB Edition” (or “Alfresco BE” as in “Bee-Edition”). Since I quite like the email “tags” suggested Boriss, I preliminarily assigned this thread to “ADDONS” pending a final decision on committee / team structure and responsibilities. I agree with the distinction Jeff made in his proposal for an initial organizational structure between “addons” and “distribution”. Apart from initial coordination / collaboration, both committees / structures will have enough on their hand to keep them busy separately. When the first major deliverables are complete and activities start to be stream-lined, they could be merged.

The current descriptions / definitions of what we want to do in this area are still high level. The web site currently emphasizes reviewing compatibility with latest Alfresco, collaborating on any compatibility issues, categorization and creation / review of tutorials and screenshots. Jeff has used the phrase “Order-endorsed add-ons” and indicated active, ongoing engagement with developers and evangelism of proper procedures as potential responsibilities. The following combines these activities and my personal “wish-list” into an initial detailed activity list as a discussion starter…

Activity #1: Form list of Order-reviewed and –accepted Alfresco add-ons

·         Non-commercial / open-source add-ons only (anyone – ourselves included – should be able to use it / modify it)

·         Add-ons listed on addons.alfresco.com only (this is and should remain the central directory)

·         Definition of detailed eligibility / acceptance criteria

o   Eligibility: Do we only include add-ons in the narrow sense of extension of Repository and Share, or tools / scripts for administration and/or development as well?

·         Successful compatibility test on most recent / most stable Alfresco CE version(s) (currently Alfresco 4.2f + Alfresco 5.0a - may be a single version in the future)

·         Successful compatibility test with other add-ons already reviewed / accepted

·         Successful compatibility test with current supported client environment

·         Basic functionality test from user perspective (using available documentation)

·         General technical review

o   Potential security issues (unsecured services, improper runAs usage, lack of traceability)

o   Potential scalability issues

o   MT capability

o   Configurability

o   De-installability / de-installation procedure

o   Development best practices (details TBD, e.g. namespacing, support of separate Repo + Share + SOLR instances, use of public services, no hard override of Alfresco out-of-the-box files or beans …)

Rationale: Our list needs to provide a significant “added value” to complement addons.alfresco.com without being “just another top 10 list” that you can find on some blogs already. The majority of us should be able to say “I would have no qualms using that add-on in production” for every add-on we list. Our tests / review should never be a replacement for proper QA by the add-on developer, instead focusing more on the “Model Citizen” aspects, interoperability and compatibility. As a group, we should have enough experience to review add-ons concerning the more advanced concepts (MT, scalability, de-installation) which a single (beginner) developer may not yet be aware of but can hurt unaware add-on users the most…

I would to see us come up with staggered sets of acceptance criteria, e.g.

·         Mandatory core criteria that all add-ons must pass unconditionally (e.g. CE compatibility, compatibility with at least X different clients, separate Repo + Share + SOLR instances, no hard overrides…)

·         Secondary criteria with limited allowed violations (e.g. improper runAs usage, compatibility with other add-ons…)

·         Tertiary criteria that will result in some sort of flagging, warning or simple documentation within our listing

Activity #2: (long term) Continuous update / maintenance of add-on list

·         Trigger #1: Updated Alfresco CE release

·         Trigger #2: Updated release of listed add-on (active trigger by developer or passive trigger due regular internal review of list)

·         Partial or full re-evaluation (similar to initial review / acceptance)

·         Creation / Setup of tooling / test automation for basic compatibility / functionality tests

o   Prepared reference environment (e.g. Amazon Machine Image incl. reference data set + CloudFormation template)

o   Source / build project to aggregate all / subset of listed add-ons for testing

o   Individual UI test script / test suite for each add-on (Selenium or anything else (not my strong area))

o   Potential test script / test suite for backend services of each add-on

·         Flagging of listed add-ons that no longer match acceptance criteria

·         Dropping / removal of listed add-ons that repeatedly failed acceptance criteria / are no longer actively maintained

Activity #3: Developer / add-on community engagement

·         Publishing tutorials / guides on development best practices, solutions to compatibility / interoperability issues

·         Active feedback / issue logging from initial or continuous review and compatibility testing

·         Review of add-on documentation / tutorials, suggestion of and collaboration on potential improvements / additions

·         Temporary stewardship of unmaintained but relevant add-ons incl. search for new maintainer / help in add-on transition phase

Rationale: We are not enough people / have not enough time to provide missing tutorials / screenshots / documentation or fix issues for the add-ons in the community that we potentially end up listing, so the focus should be on coordination, enablement and evangelism. This activity will also require collaboration with “Marketing” as speaker participation at conferences / meetups may in some cases be focused on highlighting community contributions. General CE customer stories may also be inter-linked with individual add-ons that are part of the story and these could help to promote add-ons - so much that we could end up declaring “featured add-ons”.

(internal) Activity #4: Collaboration on pre-packaged edition

·         Any add-ons included in pre-packaged edition should (must?) be from the list of reviewed and accepted add-ons

·         Alignment of acceptance criteria

·         Consolidation of test automation efforts / reference environments

Selection of add-ons

The initial list of add-ons that we subject to a review and include in the list will most likely be based on the requirements for the pre-packaged edition and our own work experience. Douglas has already posted a list of his favorite add-ons / tools earlier this month. We should pool and prioritize similar suggestions once we have narrowed down the eligibility and acceptance criteria.
For the long-term we should also decide on a procedure for adding new add-on candidates, e.g. if we just want to scan & review content of addons.alfresco.com or also provide means for developers to submit add-ons for consideration. Personally, I don’t see the need for a formal submission process and would simply include a public view of backlogged / declined add-ons which is updated / synchronized with addons.alfresco.com in defined intervals as well as reviewed by committee chair.

So far for my initial collection of thoughts on that matter – feel free to comment or correct. I may be a bit slow to answer though as I am currently running two projects at work and trying to finish a personal Alfresco PoC in time for summit.

Regards
Axel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.xtreamlab.net/pipermail/ootb-hive/attachments/20140819/f1a067e8/attachment-0001.html>