Getting Involved with Apache Bloodhound
You are probably here because you are interested in getting involved in this project but you do not know where to start. Here are some suggestions:
The most important first step to getting involved is joining in with the discussion. BloodhoundContactInfo provides all details on how to do so. You should join the email@example.com mailing list - it is always great to hear from people who are interested in the project and discussions there are the main way of influencing the project. To subscribe, send a message to firstname.lastname@example.org. There's also a public archive of the mailing list.
Once you have signed up, you will be able to provide feedback, discuss ideas for improvement and tell us that you would like to help.
We think these tickets are suitable for those new to Bloodhound to become familiar with the code base and solve small, contained issues:
Top 5 starter ticketsMore
|#119||Implement theme extensions code||starter||new||enhancement||major||Unscheduled|
|#123||Check functionality of all screens with missing Products/Versions/Milestones/Components||starter||new||task||major||Unscheduled|
|#329||Multiproduct UI: Roadmap||Bootstrap starter||new||defect||major||next 0.x|
|#339||Images in activity stream should be indicated by a small image||Activity widget starter||new||enhancement||major||Unscheduled|
|#377||Make current ticket state more obvious||ticket starter||new||enhancement||major||next 0.x|
Getting the Source Code
Apache Bloodhound is written in Python and so, if you have already successfully installed Bloodhound, you will probably have all that you need to develop it too.
The source code is available from the ASF's subversion repository at https://svn.apache.org/repos/asf/bloodhound/trunk/. To get the code, you need a Subversion client.
- Linux: There will be a command line client in your distribution's repositories (e.g. sudo apt-get install subversion or sudo yum install subversion).
- Windows: TortoiseSVN, SmartSVN or others
- Mac OS X: SmartSVN, Versions or others
The IDE that you choose to program with may also have subversion integration.
While the subversion repository is where committers are expected to submit their code, there is also an official mirror of the repository on GitHub which provides an alternative if you prefer using git. Git, of course, requires its own client programs to be installed on your computer.
To check out the subversion repository you can do this:
svn co https://svn.apache.org/repos/asf/bloodhound/trunk/ bloodhound
Using git you would instead:
git clone https://github.com/apache/bloodhound.git
BloodhoundInstall and BloodhoundDetailedInstallation both provide information about installing the necessary dependencies, but if you already have Python, python-setuptools, python-pip and python-virtualenv, proceed with the installation as follows:
virtualenv bh source bh/bin/activate cd bloodhound/installer pip install -r requirements-dev.txt
To complete the setup, the easiest option is to use the SQLite database:
python bloodhound_setup.py --project=sqlite --database-type=sqlite --admin-user=admin --admin-password=adminpasswd
after which you can run the standalone server:
tracd -r --port=8000 bloodhound/environments/sqlite
With this method of installation, the Bloodhound and Trac code is run direct from the checked out code. Any source code for external dependencies and plugins meanwhile will be found in ../installer/bloodhound/src/.
It is also possible to run multiple environments at once from the tracd development server. This means that if you have also created a PostgreSQL database for testing you can setup a new environment with the command:
python bloodhound_setup.py --project=postgres --database-type=postgres -u bloodhound -p bloodhound --admin-user=admin --admin-password=adminpasswd
and if all everything is set up properly you will be able to run both environments with:
tracd -r --port=8000 bloodhound/environments/sqlite bloodhound/environments/postgres
This is particularly useful for making sure that changes that involve database interactions work for all the databases we support.
You should find that when you make changes to the associated source code, when using the -r option on tracd, the server will reload and the edited code will be run instead of the original. In order to get templates to reload after modifications are made, you can edit bloodhound/environments/main/sqlite/trac.ini and add the following line to the [trac] section:
auto_reload = true
and repeat for the postgres environment if required.
The message catalogs won't be compiled and therefore language translations won't be available since Trac has been installed in editable/develop mode. A list of languages will be shown in the Language select on the Preferences > Language panel, but changing the Language will have no effect. For the alternative languages available, the message catalogs must be compiled.
cd ../trac python setup.py compile_catalog -f
We are more than happy to see people contributing code to the Apache Bloodhound project. These are usually expected to take the form of a patch that can be tested and commented on. For now, such patches should be posted to the email@example.com mailing list.
We do attempt to stick to the coding standards that are listed in BloodhoundDevGuide but we prefer to see people discussing code rather than holding back because it is not yet perfect.
The BloodhoundDevGuide should also be a good resource for those who want to get more involved in the project.
Google Summer of Code
We're taking part in the 2013 Google Summer of Code through the ASF, and have got several project suggestions that students can draw inspiration from. You are welcome to suggest your own idea too, please get in touch via our mailing list, more information on that here: BloodhoundContactInfo
This project has a strong focus on usability. How to use the application should be obvious, even for novice users. We believe that the application can go a long way towards helping people become intermediate users quickly too.
UI Designs and usability questions are regularly discussed on the dev mailing list - please do join in with any constructive comments. We generally expect screens to looks as in our default Ui/Layout.
Mockups can be found attached to the relevant tickets and wiki pages.