Rusteomics development guidelines

[david-bouyssie]

During the last meeting we were discussing how we could ease the Rusteomics development process, while preserving a certain degree of code consistency.

We proposed two things:

• to use the only Github Discussion/Polls to decide about the features to be implemented. For some features, detailed specification might be expected. For some others, prototypes might be preferred.
• to create an incubator (or development) branch. This is indeed useful to accept prototyped features, which could be seen as non stable features. Consequently, their corresponding APIs could be changed or removed at any time.

Shall we add something to that?

[david-bouyssie]

Proposal from @di-hardt (copy-pasted from rusteomics/mzio-2023#2 (comment))

I think we need a decision pipeline in the beginning of Rusteomics, like:

1. Proposal of a new feature (e.g. an issue)
2. Decision in a (monthly) meeting if a feature is added
3. Short brainstorm what we're expecting from that feature and how it should be implemented
4. Someone takes lead in devloping that feature
   With this we're making sure we have a working homogenous API in the end. If someone go ahead, like me in this case, it is difficult to agree on the work in retrospec.

[david-bouyssie]

Reply from @lazear (copy-pasted from rusteomics/mzio-2023#2 (comment))

I like those ideas (although approving features once a month seems a bit slow, perhaps? ... not that there has been a ton of work on the project through 😃).

I would propose that some Rust application be developed so that the rusteomics API can grow in a somewhat organic and cohesive way. For example, could leverage some of the MSP/MGF work already done and build a spectral library generator - take a peptide sequence, MGF file, scan number and write out the matched peaks. This should be relatively straightforward and would help to develop some of the core parts of the API.

I think this would solve some of the issues inherent to building a library that has no users - much easier (IMO) to build a library in tandem with an application that is actually using it.

[david-bouyssie]

My initial proposal was to create a Rusteomics incubator branch, but actually if we adopt the idea of having a Rust application leveraging the Rusteomics API, we could also eventually prototype future features within this tool (similarly to what @lazear did in Sage).
This would allow to gradually refactor the tool by moving some features from its own code base to the Rusteomics libraries.