From the makers of InspIRCd.
This page documents the aims and goals of the InspIRCd project - the targets and ideals of the developers and other team members that make the project a reality.
First and foremost, InspIRCd is a team effort, impossible for one person alone to complete, so in the InspIRCd team everyone has a voice and can freely commit code and patches for peer review.
The goals of the project are basically an ethical code, which may simply be summarised as:
| Project Design
|
- The project will perform well -- better performing algorithms should be selected over more poorly performing ones
- The project should be well commented in terms easy for new developers to understand
- The project will try to maintain a release philosophy of 'release early, release often', to aid with networks which wish to hotpatch any issues that may arise
- The project should be well documented and easy for a user with an average amount of ircd admin experience to learn and use, given adequate time to read the relevent texts.
- New features added to the project must always have some form of 'off switch', all features possible should be optional features.
- InspIRCd will always remain as modular as possible to support freedom of choice and ease of hotpatching.
|
| Developer Philosophies
|
- Developers will strive to make all features modules that should be modules, in line with the project design
- Developers will be honest, fully disclosing any bugs which occur in the software after a fix has been made available
- Developers will always strive for the most efficient design possible (in terms of performance or readability) in line with the project design
- Developers will take into consideration all requests and try to understand the user's viewpoint, even if they don't agree at first, and developers will always give full feedback as to why a request isnt being granted if it is not granted.
- Users should be thoroughly encouraged to submit patches. Even if these patches are not directly used, they may be tidied up and used as a starting point for the actual change.
|
| Quality Assurance Philosophies
|
- QA will always ensure that what they are asked to test, will be tested to their fullest extent and never rush for the purpose of calling it fixed.
- QA will always ensure the released product is stable and that all features are working.
- QA should always work with the Developers and the Documentation team when new features are implemented so that they are known to work, and users can understand how they work.
- QA should always listen to users when they say they are experiencing a bug that otherwise does not exist, in attempts to clear up the problem with said user(s) and should fully investigate the problem to ensure its not a problem they may have not caught.
- QA should always document big bugs fixes so that the Developers know that it is fixed, or what is wrong with it. With failure of communication, all-in-all it will fail.
|
| Team Work Ethics
|
- QA will work with the developers to ensure released product is the best possible product; further they will relay any new features to Documentation team to ensure the documentation is up-to-date for the users. (stated previously in more depth)
- Developers won't harass QA to test things more quickly than is sensible.
- Developers won't harass Documentation to write docs more quickly than is sensible.
- Developers will fully communicate, in private if a must, of new bugs that have presented and with their fixes; Further, Developers will provide QA with information that pertains directly to that test, so that QA and Developers are on "the same page".
- Documentation should communicate with Developers on major changes to the documents, so that they can be properly given out if needed by a user.
|
