Contents
| | | 4.4 Development Guidelines in OpenLayers | Contents | |
The development guidelines of the OpenLayers project are clearly defined:
By following specific rules 37 anyone can use the Ticket System38 of OpenLayers to advise of bugs or suggestions for new features. A finished patch file 39 correcting the bug or implementing the feature is attached to the generated ticket; the ticket status is set to review. A summary of implemented changes should then be circulated through the developers' mailing list, where they can be discussed and if need be, further modified. If no modifications are required, the patch is tested (and changed, if required) by one or more authorized project committers and subsequently integrated into the most current SVN developer's version, the Trunk [OpenLayers c].
Registered developers can set up their own SVN sandbox for testing and demonstration purposes. Each sandbox is independent of the Trunk. Within the confines of the sandbox developers have unlimited room for action and are not required to follow any guidelines.
Presently, the Project Steering Committee (PSC) of OpenLayers consists of seven members40. They supervise the project process and implement decision making processes that reflect the spirit of the community. Major decisions, such as substantial source code changes, changes to backward compatibility, dates of new releases, or the clarification of procedural questions are subject to a vote by the committee members. Each person in the OpenLayers community can use the developer's mailing list to submit or comment on proposals, however, only committee members are allowed to vote. The voting process is subject to clearly defined rules, with the possible voting values listed below [OpenLayers e]:
A proposal is accepted if the total sum of voting results totals is at least +2 and there are no veto votes (ie.-1). When submitting a veto, the voter has to provide a clear reason for the veto and, within two days, an alternative for the solution to the problem. In cases of considerable debate, the decision rests with the committee chairman[OpenLayers e].
The implementation of the animated zooming features is carried out on the basis of the above-mentioned developer's guidelines. Regular communication on available interim versions through the developer's mailing list is meant to ensure that the OpenLayers community is part of the development process. It also ensures that suggested changes or suggestions made by developers can be taken into account as quickly as possible. Furthermore, the transparency of this process results in the best possible acceptance of the feature. At this stage it is important to note that the animated zooming feature is merely intended to extend the existing API, therefore fundamental changes in the key components of OpenLayers will not be required. At the same time, the analysis of the source codes by other developers also servers as a quality assurance system.
© June 1, 2007 |
Emanuel Schütze |
some rights reserved.
This work is licensed under the Creative Commons License
Attribution-ShareAlike 2.0 Germany.
| | | 4.4 Development Guidelines in OpenLayers | Contents | |