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

Wed Aug 20 16:20:05 BST 2014

I am aware that the quality goals are quite ambitious but I do see them as goals to work towards, not necessarily goals we have to achieve fully for the first entries on our list of add-ons. Using staggered acceptance criteria we could begin with the most essential ones and when we as an organization have created an environment / process where we think we can handle more work, we could start to add criteria / promote criteria to “more mandatory” levels etc.
I definitely agree with Jan’s “think big & start small” and may have put too much of the first part down or failed to delineate between the two.

Some of the points listed by Ben I see as potential sub-activities in the area of developer / community engagement, e.g. 1) and 2) are in most part covered by the original list with the major difference that I do not see the need to pro-actively try to take control of existing add-ons if the original developer / current owner is actively maintaining it. Personally I feel that centralization in terms of hosting / ownership will not help foster more activity within the community (outside of the order) and may even stifle it (if we come across a bit too aggressive or people start using us as a place to dump their one-time half-finished projects). I would have absolutely no problem with doing this for add-ons that are already in an unmaintained state, during a temporary stewardship or if a maintainer chooses to join forces with the order.

The testing and validation parts of the activities I consider to be a necessary precursor to being able to help developers maintain their code and follow best practices. There currently is no central place that in some way codifies these “best practices” and supports developers in checking compliance as well as finding ways to improve on it. When we can provide a set of codified rules and require some level of compliance to be listed, I would assume this to act in some form as motivation to follow them naturally without us having to continuously “meddle” in the development of someone else’s personal pet project.

The part about the showcase is already being considered as a goal within the order, currently separate of ADDONS but with a definite need for collaboration.

Von: Douglas C. R. Paes [mailto:douglascrp at gmail.com]
Gesendet: Mittwoch, 20. August 2014 16:09
An: Jan Pfitzner
Cc: ootb-hive at xtreamlab.net
Betreff: Re: [OOTB-hive] WG: [ADDONS] Proposed activity details

I agree with you.

There are lots of addons we use, and I think those are "ready to be published" on the honeycomb.
We can start with them.

Douglas C. R. Paes

"Done is better than perfect"

Zuckerberg

On Wed, Aug 20, 2014 at 11:03 AM, Jan Pfitzner <jan at alfrescian.com<mailto:jan at alfrescian.com>> wrote:
hi,
I agree with Ben's bullet list - all addons should be contributed to the orderofthebee github repo.
Axel, I'm not sure if your quality goals are too ambitious. That's a lot of work that most of us will be if they are getting paid for it but I won't do any IE-testing for free ;-)
Let's think big but start small & see what we can achieve and what activities are desirable but beyond reach.
cheers, jan

2014-08-20 15:50 GMT+02:00 Ben Chevallereau <benjamin.chevallereau at gmail.com<mailto:benjamin.chevallereau at gmail.com>>:

Hi,

I would like to contribute to the ADDONS committee.

I’m quite new in this organization and I tried to read everything in this mailing list. And I was imaging something else for the ADDONS committee. I was expecting to find in this order Add-Ons “supported” by the order. A lot of people are developing Add-Ons, sometimes they publish them on addons.alfresco.com<http://addons.alfresco.com>, sometimes not. Sometimes, we can access to the code, sometimes not… Sometimes, some blog post should deserve the development of a proper add-ons! So it’s quite a mess…

So, I was expecting to find in this order a list of plugins tested, packaged, following the same packaging process, and sometimes developed by bees. It’s definitely a lot of work, and I was not expecting to find thousands and thousands of add-ons. Instead of testing and validating add ons developed by the community, the order of the bee could be an organization that:
1) hosts the code of all supported add-ons (on github)
2) review and update add-ons to follow best practices defined by the order
3) provide a continuous integration mechanism
4) helps developers to maintain their code, or propose them to transfer their code completely to the order
5) create a real showcase environment when you can see all add-ons installed

The goal is not to be concurrent of addons.alfresco.com<http://addons.alfresco.com> but complimentary. OrderOfTheBee will be the pace where add-ons are developed, supported and tested. AddOns.alfresco.com<http://AddOns.alfresco.com> will be one of the potential showcase.

Ben Chevallereau

On August 20, 2014 at 4:02:57 AM, Axel Faust (axel.faust at prodyna.com<mailto: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<http://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<http://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<http://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<http://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<mailto:OOTB-hive at xtreamlab.net>
http://www.xtreamlab.net/mailman/listinfo/ootb-hive

_______________________________________________
OOTB-hive mailing list
OOTB-hive at xtreamlab.net<mailto:OOTB-hive at xtreamlab.net>
http://www.xtreamlab.net/mailman/listinfo/ootb-hive

_______________________________________________
OOTB-hive mailing list
OOTB-hive at xtreamlab.net<mailto: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/839e534a/attachment-0001.html>