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

[Douglas C. R. Paes]

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

*"D**one is better than perfect**"*
Zuckerberg


On Wed, Aug 20, 2014 at 11:03 AM, Jan Pfitzner <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>:
>
>  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, 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 but
>> complimentary. OrderOfTheBee will be the pace where add-ons are developed,
>> supported and tested. 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)
>> 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
>>
>>
>> _______________________________________________
>> OOTB-hive mailing list
>> OOTB-hive at xtreamlab.net
>> http://www.xtreamlab.net/mailman/listinfo/ootb-hive
>>
>>
>
> _______________________________________________
> 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/ebdc5f3d/attachment-0001.html>