From PDune

Process Adoption Policy

Why have processes?

The processes and practices of Project Dune are a set of generally accepted activities that you should understand in order to contribute effectively. This wiki refers to this practice, engineering or activity as process. Please do not associate this word with "bureaucratic paperwork", it has for some such a connotation.

• If processes are understood, agreed and effective, they cause a sense of organisation's efficiency that could promote motivation for both project members and outsiders to contribute further. So it is good to have them publicly available.
• Processes should be regarded as tools. They should be created to address needs and/or risks. They should provide guidance, coherency and enforce common values as consensus. So the process-dogmatism must be tuned with the process goals' importance. Before adopting a process, we should consider how this applies to our project needs and then shape the process so that it serves those needs.

How should processes be designed/described?

Some people use BPMN process notation standard. That's ok, but not enough! Processes are more than just a workflow chart. Here are some rules for describing processes:

• Processes are created, discussed and documented as soon as we identify a need for streamlining activities in a certain area.
• Processes are described in appropriate detail. They should not detail the actual activities. They should provide a framework of reference which is used to interpret the situation and how those issues can be dealt with.
• Each process must make the value clear to the overall team. Each process should identify producers and consumers of it.

E.g: In the case of an inspection, the producers are the author, the inspectors and the moderator. The consumers are the viewers of the inspection results and quality auditors. Other consumers are the participants themselves, since with each inspection they exchange knowledge. The value in this short example are easily identified for the stakeholders of the process:

• Anyone can verify if a block of code was inspected
• Bug analysts can try to understand why a certain bug occurred and why it was not caught in the inspection (-> provide training/awareness message?)
• The inspection result statistics serve to understand certain gaps in general understanding and knowledge of development
• The inspection result statistics also serve to verify efficiency and whether adjustments in effort or estimates should be made

There will not be processes that do not currently have consumers. So, recording information that in the future might become useful is not our policy.

• If a process requires evidence, we need to consider how we can provide this evidence instead of an empty recording strategy. A balance must be found between the annoyances introduced to get the evidence and the value obtained from the evidence.
• If not understood, processes tend to make people feel uneasy (forced, stretched, etc) and thereby harm motivation. Processes maintainers should always consider:
  • to offer alternative solutions
  • to be open to new ones
  • to try to explicitly clarify the added value expected of each of the proposed practices

Our Processes

• The tools overview lists the tools and sites that are used to develop the project

The tools section only discusses the tools used to manage the project. Not the code itself, nor the libraries.

• A key activity of this project is the approach to Knowledge Management.

This area describes how knowledge is created, discussed, improved and stored in a repository for searching. It contains references to our tools to accomplish this and a couple of processes that will streamline this approach.

• Contributions to the project are documented in the approach to Contributions.

The approach for contributions is useful especially for newcomers and outsiders. The process contains templates and certain conditions that will prevent rework or reconstruction of the contributions themselves, making those contributions more efficient and ready for direct use in the project.

• The approach to Code Management is documented here as well.

Code management describes how code is committed to the version control system and the flow of activities that surround this activity. It describes how the project maintains the code, prevents bugs and the inspection and review activities.

• The project has the following approach to Release Management.

Release management describes how versions of the project are incrementing version numbers and what they mean. It makes a reference to a guide/checklist how to create releases.

• Since no software project is without bugs, here you can read about the approach to Issue Management.

Issue management describes how we deal with issues internally. It details the general use of states, provides guidelines on grading severity and describes a general workflow for an issue from start to finish.

External Links