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

[Ben Switzer]

Good day all,

I would very much like to offer my time and resources to this committee.

I agree with Bindu that what Axel has outlined is no small amount of work,
but I'm willing to assist in this effort.  I share Axel's view that this
work would provide significant value to the community.

As a community user, knowing that an add-on will work with the current
version of CE, is secure and can handle production loads is invaluable.  I
believe that organizations who are looking to implement Alfresco will also
find value in this as well, possibly assisting that organization to choose
Alfresco for their projects.

Ben


On Tue, Aug 19, 2014 at 6:48 PM, Axel Faust <axel.faust at prodyna.com> wrote:

>  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
>
> _______________________________________________
> OOTB-hive mailing list
> OOTB-hive at xtreamlab.net
> http://www.xtreamlab.net/mailman/listinfo/ootb-hive
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.xtreamlab.net/pipermail/ootb-hive/attachments/20140820/db2e1ec6/attachment-0001.html>