Split the project in parts

[simoneliuzzo]

May be at this stage of the project we could think of splitting in several parts.

For example:

• Documentation
• Configuration
• Core
• Tuning Tools
• Backend 1
• Backend ...
• Backend N
• virtual accelerator
• ...

The project is already mostly separated as above.

Each of these parts could have one person responsible with "last word" decisional power.

Each of these parts could be handled by a different lab.

The responsibility would be reassessed (on an yearly basis?) among labs and people contributing to the project.

This proposal makes sense if the separation makes sense. For example if Core and Configuration are too difficult to separate, then they would remain a single topic.

[gubaidulinvadim]

Could we do this after the workshop at ESRF? There are still parts of the project that need to be implemented (unit conversion, a standardised way to do measurements, etc), and I would not like to introduce yet another refurbishment, moving things around and rewriting tests.

Also, we have very few people actively working on the project. If we assign a responsible person for each repository, it will quickly come to one person being responsible for many things. We should first aim to attract more developers.

[TeresiaOlsson]

I think that is a good idea. On the steering committee meeting we already discussed to include a session about the organisation on the workshop since there are also other areas where we might need to modify to make things easier to run and reduce admin time. I think @swhite2401 already has this on his list of input for the agenda. Maybe it can also include the organisation and responsibility of the different packages on github?

[TeresiaOlsson]

May be at this stage of the project we could think of splitting in several parts.

For example:

* Documentation

* Configuration

* Core

* Tuning Tools

* Backend 1

* Backend ...

* Backend N

* virtual accelerator

* ...

The project is already mostly separated as above.

Each of these parts could have one person responsible with "last word" decisional power.

Each of these parts could be handled by a different lab.

The responsibility would be reassessed (on an yearly basis?) among labs and people contributing to the project.

This proposal makes sense if the separation makes sense. For example if Core and Configuration are too difficult to separate, then they would remain a single topic.

I'm not so sure about the single person with last word decisional power. So far that has not really worked so well for us and my feeling is that it's not entirely compatible with the open source culture where people can just fork a project if they don't like the direction it is going in. I think embracing the idea that decisions should be made in consensus and spend the time to figure out how to achieve that would be better for the long-term despite that development likely will be slower.

But I think it would be very nice if each package could have a main responsible who is responsible for making releases, checking that the docs is in good shape and that the package is compatible with the others. And if you have that responsibility it also indirectly means that decisions can't be made that you really disagree with because you are not going to make a release of something you don't like. So indirectly you do get the decision power.

Also, another nice part of dividing the responsibility like that is that it allows packages to be governed in different ways. So if there for example is a package which is very important for a specific lab, that package can be governed using the last word decisional power approach. And if other labs don't like the decisions, they can just develop and maintain their own version without conflicts and both packages can be part of the pyAML ecosystem. I think that is one of the great strengths of the way our configuration works. Then we can have many packages with their own governance approach. Similar to the scientific python ecosystem in general.

The difficulty I think is to handle the compatibility (this we need to practice...) but if astropy can do it we should also be able to. And then we need to define what is actually the common core? With our configuration it is possible to replace every single piece and still call it pyAML. Maybe in ten years what is left in core is just abstract classes which define the interfaces for the packages to be compatible with each other? And then all the implementions have been separated out similar to how we already do with the control system bindings.