WG meeting 2023-02-10

[lgatto]

Where: https://meet.jit.si/BiocClasses Time: 2 pm (CET)

On the agenda:

• What are the 'official' classes? Any difference between common and promoted classes (from #1). What about low level classes (see #2)?
• What is the procedure to establish a new 'official' class?
• To what extent should these be enforced during package review?

  In general, a package will not be accepted if it does not show interoperability with the current Bioconductor ecosystem.

• If not strictly enforced, should we at least require a wrapper function to convert to these? TAB: classes shouldn't strictly enforced.
• Instead of enforcing, we should convince. What are the advantages of re-using existing (core) classes? Any volunteers to initiate a short document that could be added to the contributions guide and/or a blog post? See also #1
• What improvements to S4 class development do we need (see #2)? Possibly with a focus on Bioconductor needs?

[hpages]

Hi Laurent, 2 pm CET won't work for me (that's 5 am Seattle time), but that's ok, you guys can meet without me. -- H.

[lgatto]

Sorry, I thought I selected a time that worked for all those that replied to the doodle poll - sorry for that. Feel free to comment here. I'll also publicly share the outcomes of our discussions.

[hpages]

Oh I guess I missed the doodle poll, my bad.

I'll also publicly share the outcomes of our discussions.

Great, thanks!

[lgatto]

Present: Lori, Dario, Johannes, Lluís, Malte, Marcel, Laurent Regrets: Hervé

Collaborative notes

Short introduction round

• Johannes: mass spec data/classes
• Dario: SpatialExperiment
• Lori: interested to define general classes to point package developers to during package development.
• Lluís: has packages without Bioc classes, and discussions whether using Bioc classes, other tidy classes
• Marcel: MultiAssayExperiment, how to recommend
• Malte: long time frustration with S4
• Laurent: contributed some classes in mass spec, as a reviewer how to enforce or recommend classes

Notes

• Currently we only have common classes - should we aim for suggested/promoted classes. How to add classes to the list? TODO We would need a procedure to add candidates to the class.
• How to find them?
• SE is a good example that is widely used and extended. GRanges used, not extended much. Importance of documentation.
• Need to document and promote class re-use and extensions.
• There seems to be an interest/need in compiling a list of classes and their relations.
• Difference between small list of promoted classes and a long/extensive for documentation/illustration.
• Example: SCE vs Seurat - Bioc can inherit from and convert.
• If we have a procedure to add classes, also need a way to formally remove them.
• Not only classes, also interfaces (for example to AnnotationDbi)
• Core generics - see BiocGenerics and ProtGenerics - this would need to be better documented.
• Distinction between basic/simple classes and more complex/extended classes. Good example from S4Vectors. Beware of technical challenges.
• TODO Document on when to write a new one, and when to re-use (or not use a specific class). What are the advantages of re-using existing (core) classes? If there’s no existing class, a new class is great… which could possibly become a common/suggested class.
• S4 vs S3? R6, R7? Asked Hervé about R6 and reference classes on slack. S4 is strongly suggested, but not strictly enforced. TODO - as above, make an effort to explain why Bioc promotes S4, what are their advantages?
• Possible to mix S4 and S3. Users shouldn’t bother with implementation, only know about API.
• We could define common classes by dependencies between packages
• Slack channel: see biocclasses

Next

• Organise another meeting in 3 - 4 weeks to compile suggestions for the contributions guide

Documentation needs:

• 7

• 6

• 5

• 4

[lgatto]

The main repo README has a link to this (and future) meeting notes.