OSCA maintenance team

[lgeistlinger]

This is basically a placeholder for assigning responsibilities to members of the OSCA maintenance team:

1. OSCA: @alanocallaghan
2. OSCA.intro: @lgeistlinger
3. OSCA.basic: @PeteHaitch
4. OSCA.advanced: @lgeistlinger
5. OSCA.multisample: @alanocallaghan
6. OSCA.workflows: @PeteHaitch

The assignments are subject to change upon addition of potential additional volunteers.

[hpages]

oops, sorry, don't know what happened. I tried to add @Varix to the list of assignees but somehow managed to remove all assignees instead 😅 I guess that's because @Varix has not accepted the invite to collaborate to this repo yet.

[Varix]

Hopefully it's all good now =Þ

[hpages]

yup, all good. Thx!

[PeteHaitch]

Back online after 2 weeks away (in progress triaging Slack, email, github, etc. so apologies if my reply is outdated).
Those assignments are okay with me.

[hpages]

Dear OSCA maintenance team,

Just a reminder to please add yourself to the Authors@R field of the sub-books that you are taking responsibility for once you are happy with the assignments. Thanks!

H.

[PeteHaitch]

@hpages are we adding ourselves as role = 'cre' to the Author@R field of the sub-books we are taking responsibility for?
Seems to be what's recommended by https://cran.r-project.org/doc/manuals/R-exts.html#The-DESCRIPTION-file but just felt weird calling myself the 'creator' when I've done precisely nothing so far 😅

[hpages]

Oh, because cre stands for "creator"? I always wondered. But yeah, that's what it looks like (from R-exts):

The roles can include ‘"aut"’ (author) for full authors, ‘"cre"’ (creator) for the package maintainer, and ‘"ctb"’ (contributor) for other contributors, ‘"cph"’ (copyright holder, which should be the legal name for an institution or corporate body), among others.

Oh my... that's just silly!

Anyways, that's the standard way to label someone as Maintainer isn't it?

Who cares anyway. The DESCRIPTION file was meant to be human reader friendly but the syntax of the Author@R field has made that noble goal hopeless 😞

[PeteHaitch]

I've started trying to fix OSCA.workflows (OSCA-source/OSCA.workflows#1) to make sure it builds properly in release and devel before the forthcoming release deadline.

@alanocallaghan I see you've been looking into an issue that's affecting OSCA.basic (OSCA-source/OSCA.basic#6).
Thanks you!
Are you able to try to get OSCA.basic over the line so that I can focus on OSCA.workflows (at least for this release cycle)?
I know I've dropped the ball on this and I'm very sorry, but I'm understaffed in my team and swamped with commitments.

[alanocallaghan]

To fix the AUCell problem in OSCA.basic, I'd have to remove that section at the moment I think. Could add something similar in the next release but it's too much to replace at short notice. As it doesn't run at the moment anyway I don't imagine there's much objection?

[Varix]

no objection. I run AUCell in my workflow with a few tweaks/hacks, could we include something like that in the book or do we have to keep things Ikea like and you can only use the packages as they arrive with no extra tools?

[Varix]

also I was working on adding some clustering updates but not sure if they should be in advanced or basic using Dune for robust cluster integrity. also also, the top post never got updated so I wasn't sure which I am "maintainer" of officially. I thought Basic to let @PeteHaitch work on workflows but maybe I was wrong?

[PeteHaitch]

I've only got capacity right now to try to get things to build in their current state in time for the next release.
Adding new sections or updating existing sections with new functionality in sub-books I'm responsible for will have to wait until after the next release, unfortunately.

@alanocallaghan No objection from me to your proposal re AUCell.

[alanocallaghan]

I think for the sake of pedagogy and also so that it doesn't turn into a maintenance nightmare we should avoid too much tweaking/hacking; that sort of stuff would ideally get fed into the upstream packages I suppose.

Agree, it's not the right time to be adding new content right now, sounds useful for next release.

[PeteHaitch]

So I've been able to push changes to the GitHub hosted repo (e.g., https://github.com/OSCA-source/OSCA.workflows/commits/RELEASE_3_15 and https://github.com/OSCA-source/OSCA.workflows/commits/master).
But I don't think I have permissions to push to BioC's git server:

$ git remote --verbose
origin  [email protected]:OSCA-source/OSCA.workflows.git (fetch)
origin  [email protected]:OSCA-source/OSCA.workflows.git (push)
upstream        https://git.bioconductor.org/packages/OSCA.workflows (fetch)
upstream        https://git.bioconductor.org/packages/OSCA.workflows (push)

$ git push upstream RELEASE_3_15
fatal: remote error: FATAL: W any packages/OSCA.workflows nobody DENIED by fallthru
(or you mis-spelled the reponame)

Should I?
Or do we need to do something more to transfer the BioC git repos to us as new maintainers?

[hpages]

HTTPS access is for read-only. You need to set the upstream to [email protected]:packages/OSCA.workflows if you want to push. IIRC Nitesh granted you and all the other OSCA maintainers push access to the 6 OSCA repos, so hopefully that will work.

[PeteHaitch]

Ugh what a dumb mistake!
Thanks, Herve, I've switched it and it's working.

[alanocallaghan]

I guess this is resolved now; happy to discuss/review any extra material but github issues is likely not the best place for that.

Although if @PeteHaitch wants to share some maintainership with @Varix then feel free to reopen

[PeteHaitch]

I did mean to return to this issue after the recent release because I ended up having to take care of OSCA.intro and OSCA.advanced (although I didn't yet give myself the role = 'cre' in the Author@R of the DESCRIPTION) in addition to OSCA.basic and OSCA.workflows.
@lgeistlinger are you still able and interested in being maintainer of these OSCA.intro and OSCA.advanced?

[lgeistlinger]

Hi @PeteHaitch and @alanocallaghan - sorry for a bit of silence on my end, as everyone I also ended up over-commited recently. Thanks for chiming in on the 2 issues that were brought up for OSCA.advanced - somehow I missed these. Sure I'd still be happy to help, although I think I had assumed maintainership for OSCA.intro and OSCA.advanced above?

[PeteHaitch]

(sorry, I got OSCA.intro mixed up with OSCA.basic in some of my now-edited earlier comment).

Great, if you could then please give yourself the role = 'cre' in the Author@R of the DESCRIPTION for each of OSCA.intro and OSCA.advanced, @lgeistlinger, and I'll leave the maintenance of those with you.

[Varix]

okay that makes more sense. Although I did think I was on one of those too... maybe we need to clear that up. Can we start adding things now that the new release is up?

[PeteHaitch]

Sorry, @Varix, missed that from earlier in the thread.
For now, I don't mind being maintainer of 2 sub-books but if we find there's 1 or more sub-books that you're particularly interested in developing and maintaining perhaps we can change things/

We can make your proposal a test case for how to add new content.
I'd suggest making an issue to describe the proposal at the relevant repository (based on what you described in #3 (comment), I think the Clustering chapter of OSCA.advanced is most suitable).
Once we've discussed the topic, that can be followed up with a pull request that implements the content.
How does that sound?

[lgeistlinger]

Sounds good @PeteHaitch - have updated the DESCRIPTION file of OSCA.intro and OSCA.advanced accordingly.