Contribute
How to contribute to the CPACS development
CPACS is a joint development by a large aircraft and helicopter design and optimization community coming from industry, universities and research institutions. We are happy to supporting you in your contribution to this development by providing some information about the development process.
First of all, any idea or proposal for improvement is very welcome to be sared with the community via the following platforms:
- GitHub issue board
- GitHub discussion forum
- Working groups (announced via GitHub and mailing list)
- Stakeholder meetings (announced via mailing list)
What does "development" mean in the context of CPACS?
The way in which information is modeled in CPACS files is prescribed by the so-called XML Schema Document (XSD). Thus, developing CPACS means, in a technical sense, to implement our ideas in the corresponding XSD file ( cpacs_schema.xsd ) and to agree on the hierarchical structure of the data, i.e., how elements are named and interlinked, how often they can occur or which data types are to be used. In the multidisciplinary environment in which aeronautical systems are developed today the greatest challenge is to account for the different perspectives of the various disciplines and its varying degrees of fidelity, while maintaining the single source of truth principle:
Data must be explicit and unique!
Therefore, the major part of the development comprises discussions in working groups and the basic design of the data hierarchy. So don't be scared by the technical details of the XML Schema implementation and don't worry if you're not an experienced programmer or tech nerd. Any visualization of ideas, for example in the form of tree diagrams (e.g. with Powerpoint or Excel), are already a very helpful step towards a new CPACS implementation. Nevertheless, if your ideas are already quite precise you may also find further details on the development process in the development subdirectory of the CPACS source files.
Development process
What are the detailed steps within the development process? Well, there is no prescribed sequence here, but in general the development is carried out on the basis of the following steps:
- Share your idea or change request with the community, preferably along with a description of the underlying use-case and a first draft of a solution. Use the GitHub issue board to clearly illustrate your proposal, for example by illustrating a possible data hierarchy via tree diagrams.
- The CPACS coordinator will support you in identifying the corresponding stakeholders, for example via the mailing list.
- Usually, not every stakeholder will be interested in the details of the solution, but wants to be informed on the general progress in order to introduce their own requirements if necessary. Therefore, a smaller working group will be formed to work out a detailed proposal for the XSD implementation. An iterative exchange with the entire stakeholder group ensures that all requirements are taken into account and that the actual working groups can still operate in an agile manner. The progress is transparently tracked on GitHub through the use of Kanban boards and a network graph.
- The activity will be assigned to a milestone, which is essentially the targeted release version. After the proposal is completed, the CPACS coordinator will label the milestone as Closed so that it appears on the milestone list along with the other enhancements and changes.
- Now the proposal is ready for the release process. This is described in the following section.
Release process
The release process serves to inform all stakeholders and to involve their ideas and requirements in further revisions. For this purpose, two types of preliminary versions are released before the final release. These are:
- Beta releases: These releases include all modifications and enhancements from the development process. As a prototype they are intended to be tested in practice. Depending on practical experience, further changes can be flexibly incorporated.
- Release candidates (RC): A RC is close to the final version and major adjustments should be avoided. This means that the RC serves as a final review for the official release.
The following figure illustrates the iterative release process:
