Free(B)Soft DevelDeveloper Section on Free Accessibility Solutions
Hide panels

User Live section

Are you a user, looking for available products, downloads and information how to use them?

Find our user Live section on http://live.freebsoft.org

Issue Tracking System

Open and closed bugs, patches, feature requests.

http://its.freebsoft.org

Our motto

For some people, technology makes life convenient, for others, it makes life possible.


Cooperation

The Free(b)Soft project is run by the BRAILCOM, o.p.s. company. In the development team however, both internal and external developers are equally important. If you want to cooperate with us on one of our projects, you are most welcome! Please contact us on the mailing list of the given project you are interested in.

Below is described the development model which we use. We think it's quite unique among the Free Software projects, and was put in place to ensure a good quality of software products, taking advantage of the valuable participation of external developers as well as of the stability of an established company.

Model of development for regular developers and volunteer developers

Copyright (C) 2010 BRAILCOM, o.p.s., Vysehradska 255/3, Prague 2, 12800, Czech Republic, http://www.brailcom.org

Introduction

This document is meant to coordinate the development inside the BRAILCOM company and also to set rules of collaboration with external developers. The main motivation of these rules is to maintain a high quality of developed products and simplify coordination.

Regular developer (staff)

Regular developer has a contract with BRAILCOM specifying their area of work, conditions of copyright and license.

Volunteer developer

Cooperation with volunteers is very welcome. Volunteer works in the same manner as a regular developer. Volunteer has a contributor agreement with BRAILCOM using an online registration form. Volunteer can also function as a reviewer or substitute maintainer. Order of review of patches submitted by volunteers is determined by a list of priorities.

Reviewer

Specific tasks (bugs, new features) are worked on by specific developer(s). Every task being worked on has a reviewer. Reviewer reviews finished work, provides consulting and is responsible for the quality. There can be more than one reviewer per task, but experience shows that more reviewers does not mean better quality. Therefore for a single task, detailed review by single reviewer is preferred.

Maintainer

Maitainer's responsibility is to collect patches, prepare a release and coordinate development. He/she decides when the release is ready. In absence, his/her responsibility is assumed by a substitute maintainer. A volunteer developer can be a substitute maintainer. Maintainer is directly responsible to the management of BRAILCOM.

Release

A list of bug fixes and/or new features with distinct priorities is assembled for each release. After all tasks are solved, a beta version of the release is prepared. In case the release has a deadline, the list of required changes is appropriately shortened. Beta versions with an increasing number are released until no serious issues are known. Then a stable release is released.

Testing

Ready patches are first tested privately by the original author. Only after the original author is convinced of its basic functionality, he/she asks the reviewer to conduct audit of his/her code. Testing by broader public can take place only after the patch is integrated into the master branch of the main public git repository.

Git

Every developer is encouraged to use their personal local git repository. Only when they finish work on a specific bug/feature do developers publish the change. If reviewer(s) approve the change, the code is integrated into the main git repository. BRAILCOM can create personal public Git repositories for developers on its public servers.

List of priorities

Bugs and new features have priorities. These priorities decide the order of processing of individual patches. Maintainer and reviewers respect this list. The list is dynamic, both the content and priorities can be changed. The list is compiled by the maintainer. Anyone can propose an item for inclusion.

Coding standards

Developer must ensure that the code conforms to basic programming standards. Patches should follow the coding style of the main code of product.

Documentation

Documentation is inherent part of software. It should be created continuously and updating it should be part of every patch. Its absence, incompleteness or other shortcoming can be considered a reason for not including the code change in master.

Quality of developed products

The most important metric of the developed products is their quality and stability. That should also be the basic rule for every developer. It is recommended that developers publish their code changes only after they have made basic checks and tests. These tests can also be done with help of other person but before publishing the change. By "publishing a change", it is meant announcement of finished work to the reviewer.

Copyright and license

The holder of the copyright is BRAILCOM, o.p.s. - only then will we have a strong position against possible license violators. All products, software, documentation, educational texts etc. are under GPL-compatible licenses. Authorship of the software remains unchanged by this. An exception to holding of the copyright can be independent parts developed by other parties. For example, if an output module is completely developed by another person or organization, copyright may belong to the author.

 
 

Powered byWiking1.3.2 Accessibility Statement