Scripts landing page

[hflynn]

Add a plone landing page for script info and signpost clearly from the menu

[hflynn]

Referencing ticket #11187 has changed sprint.

[hflynn]

Draft page added to plone ​https://www.openmicroscopy.org/site/community/script-sharing ready for feedback.

[wmoore]

Looking at the draft page....

If I'm a user or admin looking to browse the repository, to see if there are any scripts there that interest me, where do I see that listing?
Either we provide the hand-curated list on the plone pages and update them every time we merge a PR into our examples repo, or we tell people to browse the github repo(s) itself and tell them to download from there.

Also, The browse, download & install instructions should go before the 'submitting' instructions, since we expect more people to be accessing scripts than submitting them.

Also, what branches are we going to use on github ome/scripts? Do we have a "develop" branch that is just what ships with OMERO releases, and then "all others" for everything else (probably), or do we split 'everything else' into OME example scripts and 'contributed' example scripts (probably not)?

I think we should get rid of the forums - they're such a pain to use for this - for the 2 scripts that have been submitted so far. Attaching multiple versions of each script as the user fixes bugs etc. That is a PR - but done in a horrible way!
There are simple ways of using github - it might even be possible to submit etc doing everything within the browser. Just need to provide the simplest instructions we can.

Cheers, Will

[hflynn]

Sounds like a few of us need to have a chat about the best way forward with this - no point putting up a page on plone until we have decided the best strategy for this.

Github does appear to have a plugin thing which I think may allow users to do everything in a browser, I'll have a play with it on my home Windows laptop at some point over the next week or so (as I expect it will be mostly Windows users who would want to make use of such an option anyway) and see if I can put together an idiot's guide.

[jamoore]

Widening to omero-team. Seems like the next step is to decide: are we killing the forums? If we're keeping it, it seems like we can get something up quite quickly along the lines of the Paris requests (from Martin, etc.). If not, we'll need to make some careful decisions: whether purely github and if so, branches etc. as Will pointed out, or something else completely, at which point we need to be honest with ourselves and put time aside. Let's setup a time to chat tomorrow at standup.

[jamoore]

Brief summary of discussion today:

• Josh to modify Helen's script-sharing page with rough sketch of what was discussed.
• Look at ​https://github.com/joshmoore/omero-user-scripts as the beginning of a template for user scripts (Feel free to push if you have commit rights, but please don't push force)

[hflynn]

I don't know how other people feel, but I think we should go for improving our scripting documentation over including lots of different workflows on the landing page - while I really appreciate the effort @jamoore has put into drafting ideas for this page, it looks entirely too scary for our average user with that level of stuff on it. I think we need an idiot proof overview for this page - this is the list, install stuff you want by doing x, submit stuff to share by doing y, refer to (improved) documentation for further details of each stage. Not sure how we get to that though... Maybe by sorting the docs out *before* we do anything else?

[jamoore]

+1 on having the page simpler and things elsewhere. I was just told to add notes there, so I did. :) But I would also suggest that we need to have the minimal instructions for writers up asap. Usage won't be important until we have scripts.

[spli]

Is it worth having a structured metadata.txt file in ​https://github.com/joshmoore/omero-user-scripts which we could automatically parse in future, instead of relying on the README?

[jamoore]

Feel free to push an example. I'd probably vote for .properties, .ini, .yml, .json or similar with a ready-made parser, though.

[hflynn]

Josh's suggestions from the landing page for safe keeping:

• here we have an initially hand-curated lists of scripts that we know about.
• Curated entires will contain the name, description, and source (institution, github repo). A nice, trustworthy icon can be placed beside the CORE scripts (hosted via github.com/ome/scripts and shipped by default)
• Curated entries likely will have a (hopfully code generated) landing page with stars, tags, comments, version history, etc. At the bottom of the page there will be a list of git url+branches which have been submitted (or possibly discovered via github's "network" feature). See ​https://github.com/openmicroscopy/bioformats/network/members
• In the longer term, we can possibly crawl these URLs and discover new or updated scripts.
• We might need to request a URL per script from users, though the github READMEs are a good starting point.
• Each OMERO.web installation could eventually provide a few into which scripts have already been installed. i.e. this landing page would show ALL scripts, but OMERO.web could help with the scripts that are installed locally (possibly scraping the landing page for updates, similar to how hudson provides script updates.)

• Eventually bin/omero script and/or OMERO.web can be taught to simplify the above instructions. The more complicated instructions above, however, should allow someone to get started *today* with no code changes from us, but to the greatest extent possible preserve a history of what they've done.

[jamoore]

Helen, latest changes to script-sharing read excellently, I thought. If no one else has suggestions, perhaps we start hammering on the script list?

[hflynn]

Docs links on the plone page will need updating once we are ready to release, the urls will have changed with my docs reorganisation.