[OOTB-hive] WG: [ADDONS] Proposed activity details
Andreas Steffan
a.steffan at contentreich.de
Thu Aug 21 10:24:40 BST 2014
Hallo everybody and thanks for getting this started Axel.
I agree ADDONS and DISTRO should initially work out common things. First
and foremost, I think we should be very clear about who we are actually
targeting. With OOTB being about the CE, I assume that's generally SMBs
(and not very large scale Enterprises usage) and we focus on business
value (and not devs).
If thats the case, you can immediately draw consequences:
_ MT and scalability may not be important
_ Business value is more important than best dev practices (-> A quick
hack may work fine in practice)
_ Security (such as in runAs) may be less important
_ We may "force" upgrades more frequently and there is less need to
deal with legacy in general (e.g. IE < 9)
On the other hand, I (as a dev) volunteered to contribute to DISTRO. I
would like to enjoy doing this. I personally don't enjoy legacy a lot.
Hence, I would try pushing to follow recent CE releases unless there are
very good reasons not to do so. Like most devs, and I am pretty
opinionated. Amongst other things, I am not a big fan of amp files. I
understand Alfresco suggests to use them, but I personally do not want
to be forced to use amps.
just my 2c
Andreas
On 08/20/2014 12:48 AM, Axel Faust 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
--
Andreas Steffan
Achter Billing 14
22399 Hamburg
Germany
skype: contentreich
M: +49 1793903615
T: +49 40 23943542
F: +49 40 23943542
http://www.contentreich.de
Contentreich : Alfresco WCM / ECM, JEE, Grails
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.xtreamlab.net/pipermail/ootb-hive/attachments/20140821/e769b10f/attachment-0001.html>
More information about the OOTB-hive
mailing list