feature suggestion : add gitlab issues option

[innolitics]

feature suggestion : add gitlab issues option

[johndgiese]

@QM-OSchwab we are definitely planning on adding GitLab support at some point, however, I suspect it won't have the resources to work on this until get to a 1.0 release.

[QM-OSchwab]

I will try to ask this week to my boss the authorization to get some time to work officially on RDM. Dunno if he will agree, and if yes under which conditions, but I could have a look to this gitlab feature.

[johndgiese]

@QM-OSchwab that would be great; we would certainly appreciate any contributions! Let me know if there is anyway I can help. E.g., I would be happy to jump on a call and talk through some of the issues I ran into while working on the github backend.

[QM-OSchwab]

Hey David (John?) ,

My boss gave me an approval on principle for working on rdm. I'll have to present him more detailed information about how rdm can help us.

I don't know for the moment when I'll have time to work on gitlab feature, but I've seen that a python wrapper exists : https://python-gitlab.readthedocs.io/en/stable/.

I have 2 questions:

• have you a procedure to test the github integration alone (I mean without launching the whole rdm process) ? Does it work with private repos ?
• other topic : what do you use to transform your requirements in YML ?

Thanks!

[johndgiese]

@QM-OSchwab thats great that you got the go-ahead.

I usually go by David (although my first name is John---full name is John David Giese :) )

I will try to spend some time updating the documentation to address the advantages (and disadvantages) of using RDM.

Per your two questions:

• Unfortunately, we do not have a great way to test the Github integration at the moment. While iterating on it, I would run it against a client project. This is how I identified a number of the side-cases that it currently handles.
• At the moment, we have been editing the YML files by hand!

By-the-way, I would be curious if you had any thoughts on the format of requirements.yml. For example, we have questioned whether it is necessary to have a separate title and description. Another format for the requirements we had considered was:

1: Description goes here
1.1: Description goes here; could be markdown
1.2: Description goes here; could be markdown
1.2.1: Description goes here; could be markdown
1.2.2: Description goes here; could be markdown
1.3: More descriptions
1.3.1: More descriptions
1.3.3: More descriptions (perhaps 1.3.2 was retired)

Note that the nesting is implicitly encoded in the keys, vs being encoded in the YAML format.

This brings up a related question:

Should the YAML formats optimize for human-readability/editable or should they be generated for ease of template consumption? We are torn about this question because one of the advantages (for developers) of RDM is being able to look at the git history of the files. But for this to matter, the files need to be human readable.

[johndgiese]

Also, it is worth pointing out that one could change the format of the requirement files if one wanted to, you would just need to edit the templates to handle the new format. Said another way: you are not locked into one format or another.