I’m writing to ask what would be the general workflow for developers outside the BRG/NCCR to release a new package compas_x and have it indexed in the official compas website? Maybe we can think about having something similar to the Python Enhancement Proposal [1] to document the key ideas/references behind a package?
I think having such Compas Enhancement Proposals (CompasEP) will help both involved developers (inside/outside NCCR) and newcomers in two ways:
(1) help them have a better idea what’s coming next in the development line so they won’t waste their time doing duplicated work.
(2) help them understand the main motivations/ideas/proposed workflow behind a package.
For example, I found the ROS-Industrial Enhancement Proposal[2] pretty helpful when I first stepped into the ROS-I world. The proposal does not need to be fancy; it can be just a reStructuredText that follows a research proposal-like structure, see the ROS Enhancement Proposal’s template [3] for an example.
My envisioned workflow for the release of a new compas_x package is like the following:
(1) work on one’s own research project and prototype (and publish papers of course 
)
(2) convert one’s prototyping code to comply with compas guidelines and write docs (rewrite one’s code upon the compas cookiecutter template [4])
(4) compile a Compas Enhancement Proposal and post a message to the forum here to request reviews. (we will need a CompasEP forum topic, then)
(5) go through several iterations of review-modification until the compas core contributors/managers (probably @tomvanmele, @gonzalocasas and our colleagues at NCCR) find it appropriate to add the proposed package to the compas-indexed package family.
(6) turn the status of the CompasEP from ‘draft’ to ‘active’ and add it to the CompasEP Github repo (we’ll need to create such a repo).
If the proposed features involve addition/modification on the existing compas_x packages, my envisioned workflow would be:
(1) write up your thoughts on either GitHub features or forum post (e.g. some of my thought on compas_fab were written up in a forum post [5])
(2) if a lot of people are backing this thought, start drafting the CompasEP (can be very simple and sparse at this moment - can be used as a sketchbook to jot down ideas when you are prototyping), and
at the same time get a quick prototype out to prove the concept
(3) following up your initial feature request post, provide the link to your prototype code with instructions to reproduce your results.
(4) review/discuss/improve
(5) complete the CompasEP and submit a pull request.
As a student/researcher outside the NCCR organization, I am fascinated by the idea of having a unified interface for our users, in a CAD-independent / version-controlled way. For my future work, I’d love to package my core computation engine as a backend, expose python bindings or message/service protocols, and finally get connected to the generative design/visualization environment via the infrastructure provided by compas community.
I believe this is a good way to deliver research implementation in the field of computational design/structure/fabrication to increase reproducibility, and will certainly benefit both our community as a whole and the visibility of an individual’s work. Also, engaging with a community that works towards the same high-level goal always makes one feel good 
I don’t have a ready-to-go project at hand as an example to back up my thoughts here (I’m working on it…) But I’d like to hear what other people think about this proposal of CompasEPs.
[1] https://www.python.org/dev/peps/
[2] https://github.com/ros-industrial/rep
[3] http://www.ros.org/reps/rep-0012.html
[4] https://github.com/BlockResearchGroup/cookiecutter-compas-package