Closed WilfridSKendall closed 4 years ago
martintoreilly
commented
5 years ago Hi @WilfridSKendall. In general, I'd prefer not to fork to a new repository when making the public release. Making an "event horizon" in the project's development history seems like quite a downside to me. What are the blockers to just flipping the public switch on this repo? If it's just cleaning up some issues and meeting notes, I'd suggest we just do that here.
martintoreilly
commented
5 years ago In terms of the to-do list, I'd also suggest consolidating user documentation from the wiki into a "read the docs" style "docs" directory that we can expose as a project website via Github pages.
martintoreilly
commented
5 years ago On the forking the repo question, do I have the wrong end of the stick? Is this about changing the repo that future development will occur on or making a new "deployment" fork for our particular deployment of the Detector Checker app?
tomaslaz
commented
5 years ago Hi @martintoreilly @WilfridSKendall What are the blockers to just flipping the public switch on this repo? If it's just cleaning up some issues and meeting notes, I'd suggest we just do that here.
I was thinking that keeping meetings notes, issues, internal wiki, etc. is good for record keeping but I also understand your point that we don't want have zombie repositories or repositories duplicating the code. I guess we need to decide if we want to keep the issues/wiki (unfortunately GitHub does not allow to have private issues for a public repository), and if so, we need to create an issue-only repository. Another question would be whether we want to move from development in a private repository to a public one. I do not have a strong opinion about this personally, however, one of the institute's missions is to be as open as possible :)
In terms of the to-do list, I'd also suggest consolidating user documentation from the wiki into a "read the docs" style "docs" directory that we can expose as a project website via Github pages.
Currently wiki pages are for internal use only and we need to check that there is no sensitive information there. The current wiki pages are not about how to use the webapp or package but about development.
On the forking the repo question, do I have the wrong end of the stick? Is this about changing the repo that future development will occur on or making a new "deployment" fork for our particular deployment of the Detector Checker app?
I guess this depends on how we will decide to deal with the issues (notes).
martintoreilly
commented
5 years ago I guess that making the source code open in my mind says to people, feel free to deploy your own version and tweak it as you see fit, so the deploy to Azure instructions feel like a necessary part of a good practice source release.
How about we do a collective review of the issues and wiki to see if there's anything we're worried about the wider world seeing and make a decision then?
@WilfridSKendall, @ejulia17 As the folk who will be continuing development on this codebase after this project is over, could you both have a think about how you feel about developing on an open repository? From a good practices viewpoint, I'd strongly recommend this rather than maintaining a private "development" repository and a separate "clean" "release" repository. However, if this is something you are too uncomfortable with we can discuss options.
OscartGiles
commented
5 years ago One option if we don't think the wiki is useful for others, is that we just disable it (https://help.github.com/en/articles/disabling-wikis) which hides it but doesn't delete the content.
ejulia17
commented
5 years ago Thank you everybody for this discussion; apologies coming in late. I'm sure we can find a good solution. Currently at a Turing Health Data meeting in Manchester, I also just had a lunch break chat with another RSI and with a data scientist from which I learned that it's a bit of a weakness of github that you can't mix public and private within one repository and that some use gitlab instead which allows a hierarchy of group permissions. (But other than that, they said, for a small project like ours, gitlab may amount to killing a fly with the sledgehammer.)
Martin's suggestion of a clean up of issues may be taken as an opportunity to make sure we are on top of what is still relevant at a time of a handover. There must be also be way to conserve what we don't want to delete but hide from public access, maybe without opening another repository, e.g. in the form of a document containing these but stashed away in the private Wiki that Oscar mentioned. I am not sure why we need them again, but it feels intuitively very wrong.
Another question is around current issues, and that is linked to what Martin brought up regarding development. Having more than one state of the package does potentially set us up for confusion, so it's very true that we need to think carefully about this. I'm in the process of discussion this with Wilfrid via emails. More soon... Julia
WilfridSKendall
commented
5 years ago Dear all Sorry for slow reply. In my defence, yesterday early in the morning my second grandchild arrived. I was asleep at the time, but you'll understand it's all been a bit distracting.
1: It seems that none of us are strongly committed to the two-repository solution, so I suggest we don't.
2: A "code review" sounds like a good idea. I take it that we don't envisage a review of actual code line-by-line, but a review of what is on the repositories (DetectorChecker and DetectorCheckerWebApp). Why don't we do that on Wednesday 13 March when we meet at 1500? I envisage it being a run-through of what is on the repositories, deciding to keep / amend / hide / delete [possibly "delete" including "store elsewhere as archive"]. We'll all need to do a bit of homework beforehand, because we'll need to complete the process more or less within the hour. According to my recollection, much of what is there is now disposable (comments on issues now resolved, minutes of meetings we don't need to refer back to ...).
3: If so, then actions become:
Our immediate aim is now a modification of "to freeze current GitHub DetectorChecker development project by end of March", namely, by end-March to insure a tagged Git revision ("DetectorCheckerPublic1"?) which works properly for our immediate purposes and is used in the public webapp.
Does this make sense to everyone?!
OscartGiles
commented
5 years ago Congratulations @WilfridSKendall .
This all sounds sensible to me.
WSK will try to find some time between now and then to look at how publication of webapp to Azure works in practice.
You may wish to hold off on this until next week as I will update the instructions to show how it works with both a development and public-facing websites. I'll get this written up on Monday and let you know when its online.
tomaslaz
commented
5 years ago Do we keep this open until we make both repositories public?
From last time, notes on Handover:
Not yet done
Need to grant public access to code: a: Oscar to unify the detectorchecker and testdata sources into one GitHub account. b: Oscar forks to new Github repository (owned by Turing) which then becomes the repository for publicly available code. (Need to avoid transferring webapp repository, issues, meeting notes!) Oscar fix webapp on web to point to publicly facing code, and also create detectorcheckerdevelop.azurewebsite.net site to point to code under development. Aim to get things done by start of Manchester workshop at end May.
Request just now sent through and now approved. NOTE expiration date is 30 June, extend before then! Oscar to put entire REG team on access. Once credits come through: when ready for publication, Oscar to ensure both webapp sites (public-facing and develop) use the new supply of credits.
Aim to freeze current GitHub DetectorChecker development project by end of March.