Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

missing trajectory dimension in h.22 #136

Closed
castelao opened this issue Jul 17, 2018 · 6 comments
Closed

missing trajectory dimension in h.22 #136

castelao opened this issue Jul 17, 2018 · 6 comments

Comments

@castelao
Copy link
Member

Example H.22 uses a dimension trajectory that is not declared.

Is that a real mistake? Shall I do a pull request adding trajectory to dimensions?

@dblodgett-usgs
Copy link
Contributor

Looks like a mistake to me! Want to PR the fix?

castelao added a commit to castelao/cf-conventions that referenced this issue Jul 22, 2019
Variable trajectory uses dimension trajectory, which was missing.
@dblodgett-usgs
Copy link
Contributor

Fixed in #185

@davidhassell
Copy link
Contributor

I agree that this is a defect, and the suggested fix is correct.

Sorry to be pain, but I believe that this shouldn't have been merged and closed yet, as the required three weeks' of "no objections" has not elapsed. As you know, I am uncomfortable with merging anything until we have an agreed strategy on how to do this. Verbal consensus appears to favour merging into the master branch once an issue is concluded, and the issue being closed (and I, too, am happy with this) - but this has not been formally decided upon and written up. This is perhaps the most pressing governance issue that needs resolving, as there are accepted pull requests that the community would benefit from being incorporated.

Thanks,
David

@davidhassell davidhassell reopened this Jul 22, 2019
@dblodgett-usgs
Copy link
Contributor

@davidhassell -- my interpretation of the rules that we agreed to here: http://cfconventions.org/errors.html are that if there is no disagreement on an error in the document that we should feel free to modify the specification. Given that this issue lingered open with no objection for nearly a year, I saw it as a clear candidate to fall under this rule.

That said, I think I've been in a move fast and break things mode -- a bit to push the community to actually use github through a bit of learning so -- in this case, this may have warranted a bit more deliberate approach. Maybe lump this into the pile of things to consider in #172 and move on?

Best -- Dave

@davidhassell
Copy link
Contributor

Oh - I thought it was originally posted in 2019, not 2018! So 3 weeks is definitely up and it's perfectly OK to accept. Sorry, @castelao!

It would useful to say in the issue something like "This defect has gone disputed for > 3 weeks, so it is being accepted, I think", so that people can see that the rules are being followed,

I totally agree with your interpretation, @dblodgett-usgs, I'm just concerned that the procedure for "make the change and/or merge the pull request" has not been defined, yet. We'll carry this on off this issue...

Many thanks,
David

@davidhassell
Copy link
Contributor

3 weeks have passed with no further discussion, so we can accept this defect. Thanks, @castelao

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants