-
Notifications
You must be signed in to change notification settings - Fork 3
Home
from March 2021 onwards
Apologies: James Reid
Agenda:
Main aim: decide how to manage / publish the GEMINI content / pages using GitHub.
Other item: possibility of a "UK Standards Meet-up/Webinar"? (Jo)
Present: Peter Parslow, Sean Gaffney, James Reid, Edd Lewis, James Passmore, Apologies: Jo Cook (leave)
Metanorma: needs a style template set up first, which is often contracted to the organisation (but is documented). We don't know if it supports our 'common content'/styling requirement.
GitHub Pages (Jekyll static pages):
Write in ASCII Doc leaves options for publishing using Metanorma or others. Internally, Metanorma uses XML, but it can take ASCII Doc (& others) as input.
Should consider:
- one off skills/work to get from where we are to where we want to be
- the skills required to then maintain the document, however marked up
- the tool for publishing from that
We discussed the pros & cons of maintaining the content in AsciiDoc or HTML, but still don't consider we are equipped to make a call. James P urged us to remember that so long as the change from the current system is lossless, the choice of approach is not a 'for ever' decision.
WG members to look at https://github.com/agiorguk/gemini/blob/main/resources/Readme.md
Sean encouraged us to look at his two issues, at least to advise MEDIN: #68 and #69
Present: Peter Parslow, Sean Gaffney, James Reid. Then James Passmore after we'd finished. Apologies: Jo Cook, Edd Lewis
Edd reports: "Metanorma does work quite nicely & I personally like the idea of using common tooling with OGC/ISO
I haven’t yet managed to get it to deploy to GitHub Pages automatically"
Brief discussion:
- the fact that we'd like to get back to actually improving GEMINI! We don't really feel that deciding/selecting a publication process is "our job"
- possible pros & cons of Metanorma and 'native HTML' publication
- the list of GEMINI pages at https://github.com/agiorguk/gemini/blob/main/resources/Readme.md
- we need to push for agreement of a quorum: perhaps four? But we haven't had four people at a meeting since late July.
- Peter will close https://doodle.com/poll/vb6wq3ckxtpip7g8 this afternoon; Sean now can't make 7th October; James would prefer not the afternoon of 7th
Present: Peter Parslow, Simon Roberts (briefly), Edd Lewis Apologies: Jo Cook, Sean Gaffney, Simon Roberts
Brief discussion on Peter's contribution to https://github.com/agiorguk/gemini/issues/64. We need to get more members to interact there and/or attend.
Present: Peter Parslow, Simon Roberts, Edd Lewis Apologies: Jo Cook
DELETE 1. update on AGI Council & amending content on the website (Jo) 2. how to manage the content on GitHub (Edd)
Following an approach that OGC use to publish standards from GitHub, he has the static pages converted to Markdown from which he can generate very plain HTML - with no styling. Needs some more work on 'build' from Markdown to styles.
Perhaps more importantly, how to produce two pages with a lot of common content? "Docsy" should support this. There are other possible systems. We believe Jo has experience too.
Peter to ask Gobe what OGC use.
Some discussion of issues: #3 Sean to continue and to group the changes into 'easy' and 'requires discussion' #12 further work required to make it actually user friendly - a new action on Peter #29 need others to confirm whether it is actually non-breaking #30 some further thought will be needed
Present: Peter Parslow, Sean Gaffney, Simon Roberts, Jo Cook Apologies: Edd Lewis
Introducing Simon Roberts of Improvement Service (Scottish local authorities)
Jo reported that AGI Council support the idea of moving some or all of the GEMINI pages to GitHub (for management & publication). AGI Council require a written description of our control/publication process. They don't need an exact match of style, but want it recognisably AGI. The GEMINI pages are among the most visited pages of the AGI site. Suggestion: move the "element" pages.
Simplest: pages exist as markdown, in a "documentation" branch in the repository - commit to a "published" branch. We need to agree how to handle the code changes. But this doesn't handle the shared content bit across dataset/service/summary pages.
A bit more complex: use "read the docs" - Jo think this can handle common text blocks. May be more tricky
To do: work through the page hierarchy (web) and decide which ones move. Action: Peter to upload the 'web' picture & initiate discussion. Action: Jo put up a starter document on our change / publish process
Issue #12: Peter to tweak diagram; Jo to suggest words. Issue #29: some discussion & progress
Scotland has a well used planning data system, called "uniform" from IDOX. It would be good to get them involved / aware. Simon will sow seeds on data standards as requirements in the planning system.
Present: Peter Parslow, Sean Gaffney, Jo Cook Apologies: James Reid, Edd Lewis
Agreed to rename the project's "For closure" column to clarify the role it plays in comparison to GitHub "closed" status.
BlueStar, AGI's web support team, have requested payment for changes; AGI Council will be discussing this on Tuesday 20th, as part of a wider concern that their current contract does not support sufficient flexibility of the website. After that we will know more. One possibility would be to host GEMINI content off site (e.g. on GitHub), but it is part of a wider question. Raise an issue for this - the overall management of GEMINI pages - to provide a space to track the conversation.
issue #25: close, open a new issue on the use cases of ISO 19139 metadata for e.g. feature instances (& the questions of multiple hierarchyLevels in one file).
issue #12: we feel the diagram is incomplete. Peter to propose a fuller one
issue #28: we agreed changes to a number of things that are wrong with the description of this element (Domain, Guidance, Comments, description of encoding example). Move to "To implement".
Present: Peter Parslow, James Reid, James Passmore, Apologies: Jo Cook, John Tate
Peter explained the use he'd made of the "For closure" column (sent to AGI, waiting for them to publish) and the new "bundle" tag (i.e. where the fix should be bundled into a release, e.g. because it would require software change. We agreed to rename this to "release", and introduce a "immediate" tag for issues that can be implemented immediately.
We reviewed the discussion & agreed the implementation for #18, #19, #28, #57, #60, all of which can be implemented for immediate release.
We discussed #3 and consider it can be closed with no change; action Sean (as initiator) to confirm (or say why not)
We discussed #12 and actioned James to draft a flow chart & Peter to ask how that could be emebedded.
We discussed #16 inconclusively.
Peter to book fortnightly meetings at this time (3pm Thursdays).
Present: Peter Parslow, Sean Gaffney, Jo Cook, James Reid, Edd Lewis Apologies:
- issues pending closure - two closed issues were removed from the project
- issues pending release #31 proposed new page: not consistent between "UK GEMINI" and "GEMINI". Should
- issues for review: #25 - Jo to look, and Sean to look at MEDIN Schematron (for interest) Others resolved & moved to "to implement"
Note we have 1 in "for review", 6 in "to implement" (one of which should wait for a bundled release), 2 in "pending release", awaiting the next five.
Further discussion on #27
Present: Peter Parslow, James Reid, Edd Lewis Apologies: Sean Gaffney, Jo Cook, James Passmore
- we confirmed the changes for three issues, meaning that Peter has two HTML & one 'tracked changes' document to send to AGI's web team. These are in the "Pending release" column of the project. Note: this will result in the GEMINI 2.3 version date moving to 'now', and relevant entries shall be made in the change log.
- we agreed to close two issues with no change (there are for now in the "For closure" column of the project)
- we agreed solutions to two other issues, which are now in the "to implement" column. Peter to make the changes & release them with the others
- we briefly discussed one other, but could not proceed (assigned now to Jo)
- we discussed another and moved it back from "for review" to "under discussion".
- we'll meet again next week. Peter to book, from the preferences on the Doodle poll
Present: Peter Parslow, Sean Gaffney, James Reid, Jo Cook, James Passmore, Edd Lewis
Apologies: Rob Walker
This was our first meeting using the GitHub repository to drive the agenda. Peter introduced the columns in the project board, which have cards to describe what they are for. We agreed that not all resolved issues need to wait for a release, and that https://github.com/agiorguk/gemini/issues/9 is a good example (so Peter was right to publish it & close the issue).
- We will use meetings to agree resolutions that appear to have emerged in comments; these issues will be in the "For review" column.
- We will use meetings to agree that an implementation does in fact close an issue; at that point, a closed issue will be removed from the project.
- Our process & policy will emerge over the next few months through working on some issues. We will document discussion on versioning & release rules at https://github.com/agiorguk/gemini/issues/27 and create a document from it at some time.
- we agreed that it had been right to resolve, publish, and close one issue; we agreed the solution to two others; discussed one other (without agreeing the solution), and raised a new one.
- we should be able to create a change log for a release (or perhaps even between releases?) automatically from GitHub; needs some investigation
- our rule for deciding when to release will emerge from experience
- @Peter to issue a Doodle poll for a next meeting in the first few days of June
Present: Peter Parslow, Sean Gaffney, James Reid, Jo Cook, Rob Walker
We looked at the two repositories and discussed our way of working. We will try to work in GitHub and have (roughly) monthly meetings to actually decide whether a 'solution' is the solution. That is, between meetings, we can put an issue in the status "for review", but only set it "agreed" at a meeting.
"Agreed" means that we know what we want to change, but someone has to go & do it. At that point, we'll assign the issue to someone to implement the change - offline, pending release.
Next meeting: 3pm (BST) 18th May
Action: Peter to reverse the "Non-breaking" label, i.e. remove it & add a "Breaking" label to the others Action: Peter to document what the labels mean (in the Readme) Action: Peter to create status ("can ban") columns, and assign the open actions to them. Probable statuses: new, in progress, for review, agreed