~~ Licensed to the Apache Software Foundation (ASF) under one ~~ or more contributor license agreements. See the NOTICE file ~~ distributed with this work for additional information ~~ regarding copyright ownership. The ASF licenses this file ~~ to you under the Apache License, Version 2.0 (the ~~ "License"); you may not use this file except in compliance ~~ with the License. You may obtain a copy of the License at ~~ ~~ http://www.apache.org/licenses/LICENSE-2.0 ~~ ~~ Unless required by applicable law or agreed to in writing, ~~ software distributed under the License is distributed on an ~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY ~~ KIND, either express or implied. See the License for the ~~ specific language governing permissions and limitations ~~ under the License. ------ Get involved ------ ------ DD.MM.YYYY Get involved The Apache Droids Project is an {{{http://www.opensource.org/}Open Source}} volunteer project released under a very liberal license. This means there are many ways to contribute to the project - either with direct participation (coding, documenting, answering questions, proposing ideas, reporting bugs, suggesting bug-fixes, etc..) or by resource donations (staff time, conference presentations, publicity, software) and even general hardware/money {{{http://www.apache.org/foundation/thanks.html}donations}} via the ASF. To begin with, we suggest you to subscribe to the {{{./mail-lists.html}Apache Droids mailing lists}} (follow the link for information on how to subscribe and to access the mail list archives). Listen-in for a while, to hear how others make contributions. You can get your local working copy of the {{{./source-repository.html}latest and greatest code}} (which you find in the Apache Droids module in the Labs Subversion code repository). Review the todo list and the issue tracker, choose a task. Perhaps you have noticed something that needs patching, or have a new feature to contribute. Make the changes, do the testing, generate a patch, and discuss on the dev mailing list. (Do not worry - the process is easy and explained below.) Document writers are usually the most wanted people so if you like to help but you're not familiar with the innermost technical details, don't worry: we have work for you! Help Wanted Here We would be glad to have extra help in any of the following areas: * Assisting to improve documentation. * Testing Apache Droids (especially its less-frequently-used features) on various configurations and reporting back. * New samples, droids and plugins to concisely describe and demonstrate features. Such samples can also enable automated testing. * Debugging - producing reproduceable test cases and/or finding causes of bugs. Some known bugs are informally listed on To Do, and some are recorded as issues (see explanation below). * Providing new use-cases and requirements. If you think that Apache Droids does not quite meet your needs then tell us about it. * Specifying/analysing/designing new features - and beyond. If you wish to get further involved with this, please join the labs mailing list, install and try out Apache Droids and read some of the mail archives. You should have a reasonable fluency in Java technologies, some Spring and Ant skills, and a basic understanding of the Apache Droids architecture - don't just say "it should have XYZ" without reading anything first - because chances are, somebody has already thought of that feature!) * ... and there is just one other thing - don't forget to tell everyone who asks, how great Apache Droids is! The more people that know about and start to use Apache Droids, the larger the pool of potential contributors will be. Procedure for reporting bugs and issues and enhancement suggestions If you think that you have found a bug or you have a suggestion for improvement, then please discuss it on one of the {{{./mail-lists.html}mailing lists}}. However, please check our Issue Tracker first as it may be already reported. The {{{./issue-tracking.html}Apache Droids Issue Tracker}} collates our known issues. Obviously not every issue is listed there. Some issues have been discussed on the mailing list but do not yet have an issue recorded. The Roadmap is the best way to get an overview. The Unscheduled list also needs regular review, and committers will schedule some of those for the next release. When creating a new issue, please provide a concise Summary Title and a short Description. Add further information as Comments and include links to the mail archives. The normal procedure is to discuss the issue on the mailing list and then add relevant notes to the issue tracker, otherwise it becomes cluttered. SVN Usage An overview of how to use Subversion (SVN) to participate in Apache Droids development. Do not be afraid - you cannot accidently destroy the actual code repository, because you are working with a local copy as an anonymous user. Therefore, you do not have the system permissions to change anything. You can only update your local repository and compare your revisions with the real repository. The {{{./install.html}Installing Apache Droids}} document explains. Coding Guidelines We use coding standards so that Apache Droids source code is easy to understand, to maintain, and to enhance. We are using the commit-then-review approach. Still, nothing untested should be committed. First test then commit!!! <>: We do not use the <<<@author>>> tag in java code and the corresponding tags in other format. We think this helps feel more like community development. Only produce code conforming to the Java code conventions, as they are set down on the page {{{http://www.oracle.com/technetwork/java/codeconvtoc-136057.html}CodeConvTOC.doc.html}} Indentation is 2 spaces for any type of file (being java or xml or ...). No tab stops. How to prepare and contribute patches If you use the current development version of Apache Droids via Subversion, then first check what files have changed. ------------------------- svn update; svn status ------------------------- Make a patch for your changes. ------------------------- svn diff > mypatch.txt ------------------------- Patch for a specific file --------------------------- svn diff src/documentation/content/xdocs/install.xml > install.xml.diff --------------------------- It is better to prepare the patch from the <<<$DROIDS_HOME>>> directory so that it contains a definite path to the document. However, be careful that the patch does not contain other work-in-progress. For more information about working with SVN, see {{{http://svnbook.red-bean.com/}Version Control}} with Subversion - the opensource SVN book. <>: Please send all contributions via our issue tracker. and specify the Apache Droids version or svn version of the source. It is always a good idea to check the Apache Droids issue tracker before diving in.