Share Extras is an open project and we encourage you to contribute to your favourite add-ons by forking the public code.
Non-coders can also contribute just by trying out the existing add-ons and providing feedback via the mailing list or in the Issues section of the relevant project.
An enhancement to an existing add-on may be a new feature, a translation in your local language or a fix for a specific issue.
If you have an idea for an enhancement that would benefit you or are willing to implement an enhancement yourself, please start by checking in the Issues section to see if anyone else has logged something similar. If not, you can add a new issue and tag it as an enhancement.
By submitting any additional code, configuration or documentation, you agree to license the content under the current project license. At the time of writing this is the Apache License 2.0.
Anyone can create a new add-on project using free tools such as Git. We encourage you to publish your code as open source on a public repository - we use GitHub but there are many others out there.
Once you have published your code and created an initial release, you should strongly consider listing it on the Alfresco Add-ons site.
You add-on will then be available to the community to use and improve. There is no need for you to do anything further, however, some people have expressed a desire to contribute their add-ons to Share Extras.
Contributing an existing add-on will give you the benefits of being associated with a larger project, but it does not absolve you of responsibility! What this generally means is that you will remain the project leader responsible for managing the code.
If you are interested in contributing an existing project, then please send an email to the mailing list in order to start the discussion. Please provide the URL of the public repository.
The Project Leader(s) will decide whether a new add-on should be accepted. If accepted, a new project will be created within the share-extras organisation on GitHub, the existing code will be forked to there, and share-extras on GitHub will become the main home for your code.
By submitting code, configuration or documentation for your add-on, you agree to license the content under the current project license. At the time of writing this is the Apache License 2.0. You must have the authority to release your content under this license, but note this does not affect ownership of the content.
Once an add-on is considered sufficiently mature, it can be promoted to a top-level add-on. Top-level add-ons are listed in the Project Description text on the Share Extras front page.
The Project Owners will decide whether a sandboxed add-on should be promoted. Typical criteria for promotion include, but are not limited to the following.
An acceptable project name has been defined and this is consistent across all add-on files
An appropriate source tree layout has been defined, consistent with the Sample Dashlet project, including the latest stock Ant build script build.xml and library dependencies from that project
All code to be consistent with the Alfresco Coding Standards, specifically using 4-space tabbing, spaces instead of tabs and braces generally on new lines within JavaScript and Java code.
A MAINTAINERS.txt and README.txt file exist in the add-on's base directory and contain complete and relevant information for the add-on
All add-on files must be packaged in an appropriate directory structure and should avoid the use of Alfresco-reserved packages (e.g. org/alfresco for web scripts) in most cases. The package org/sharextras can be used as a base package.
No core Alfresco or Share files should be duplicated or replaced by files within the add-on
Web scripts may be overridden only where required in order to implement the capabilities of the add-on. Where overridden only modified files should exist in the add-on source tree.
Client-side files should be placed inside a project-specific directory, usually extras/components, and not in the base components or modules directories used by the core Share files
Client-side JavaScript should be normally be implemented in dedicated classes within the Extras or Extras.dashlet namespaces, using the standard Share pattern utilising YAHOO.lang.extend. JSDoc comments should be used to document classes and all public variables and functions.
All strings appearing in the add-on UI must be externalised in message bundles
It must be possible to package all add-on files in a single JAR file, using the Sample Dashlet build script, and the build should run without errors
No errors should occur during start-up of the repository or Share web applications with the add-on installed
A wiki page has been defined documenting the add-on with screen shots, installation instructions, build instructions and known issues documented
The add-on should function without errors, and should have been tested, in recent versions of Firefox, Google Chrome and Internet Explorer
No issues tagged with Priority-Medium or higher relating to the add-on should be open
The Project Owners may decide to remove a sandboxed add-on which has not been promoted within a reasonable time.
