Closed ruebot closed 8 years ago
👍 — we can add it back in if/when the use cases come in.
:+1:
Process wise ... if we just want to register +1 without a comment, should we just do the emoticon response, or is it easier to track with full comments?
And anyone who wants to use a non-PCDM collection concept with this cardinality constraint is free to do so.
I'm in favor of respecting emoji responses on the top-level comment as votes. This will keep the comments from getting unnecessarily cluttered.
Perhaps this should be the only way to vote?
Just a note, I grep'd across the repo for AdministrativeSet
and this was all I found. But, if anybody recalls it being referenced anywhere else, let me know and I'll update the PR.
:+1: to removing
Old use case documentation: https://github.com/projecthydra-labs/hydra-works/issues/17
@ruebot can you bump the version information in the ontology with this PR? https://github.com/duraspace/pcdm/blob/master/models.rdf#L19-L20
@acoburn done!
...and that can all get squashed with the new GitHub functionality depending on who clicks the merge button.
I'd expect the prior version defined here to be the same as the current published version. My point is that the never was a 2015/10/14 published version.
@acoburn ah, ok. I'll await confirmation from @awoods to see what he has on his end on the microinstance.
I agree with the observation that @acoburn is making regarding:
the prior version defined here to be the same as the current published version.
This raises a point about ontology releases. I suspect we will not want to publish ontology updates with every commit, but instead decide that enough commits have passed to warrant a "release". It would be nice if we had a process around releases.
the prior version defined here to be the same as the current published version.
That was my intent in the commit. The current version is 2015/10/14, and the new version would be today's date. So, I set the current version to today's date, and the previous version, to the current version. That sounds clear :smile:
...but, If I'm understanding things correctly, 2015/10/14 was never published?
All that said, do we create a separate issue to document when and how to do a release?
On a related note to:
do we create a separate issue to document when and how to do a release?
Were there any PCDM governance actions that have come out of recent discussions at LDCX or the like? It seems like release processes would roll under the broader topic of PCDM governance.
@awoods here are the notes from the session. But, iirc, action item-wise, the main item was an MOU.
...as for the release process, IMO, that would be up to the committers to determine.
Can we separate the removal of AdminSets from the process for release into a separate issue?
On Mon, Apr 18, 2016 at 5:08 PM, Nick Ruest notifications@github.com wrote:
@awoods https://github.com/awoods here https://docs.google.com/document/d/1hhsFx-GQVMJ_Np7C5jcyhHf3Y1DOIb4-WmpWSaSPu8U/edit are the notes from the session. But, iirc, action item-wise, the main item was an MOU.
...as for the release process, IMO, that would be up to the committers to determine.
— You are receiving this because you are on a team that was mentioned. Reply to this email directly or view it on GitHub https://github.com/duraspace/pcdm/pull/50#issuecomment-211641099
Rob Sanderson Information Standards Advocate Digital Library Systems and Services Stanford, CA 94305
Please roll this commit back, per: https://github.com/duraspace/pcdm/pull/50/files/f7c341d6f03e64f6ce3172de5d3b60822adb9cee#r60971777
@awoods @escowles my apologies about that. I should have caught that before I pushed.
Might as well finally force the issue on this one since it has come up on the list from time-to-time. @duraspace/pdcm-committers and community chime in.