Article versioning policies

[mrshirts]

First pass at article versioning policies, @davidlmobley @dwsideriusNIST @dmzuckerman.

[mrshirts]

Addresses #176

[dwsideriusNIST]

Sorry for the tardiness... I'm not receiving real-time updates while the US Govt is shutdown.

I'll submit some major revisions ASAP... this PR partly contradicts the guidelines I added to https://github.com/livecomsjournal/article_templates/blob/master/information_for_authors.md

[mrshirts]

this PR partly contradicts the guidelines I added to

OK, I wasn't quite in agreement with these versioning guidelines (as I thought was clear in the discussion). Fundamentally, I think we should let them handle their internal versioning as they want to, as long as it agrees with the other guidelines. For example. I think that it doesn't make as much sense to have them doing multiple versions in the reviewing process.

I apologize for missing this in the commit; I didn't notice that this file had as much information as it did.

I also wonder if we want to have all of this information in the templates, when many of these things should probably be in the main author information file in livecomsjournal.github.io; with just instructions for doing latex. For example, the "Example scenarios for authors" and "Example scenarios for readers" seem like they be in the same place as other instructions, and keep instructions directly related to the latex templates in this file.

[dwsideriusNIST]

Let me also apologize for mangling the approval of the versioning guidelines. I had the impression that my proposal had endorsement of the managing editors and then proceeded accordingly. All in all, though, I don't think that we are too far apart in the basic principles of the versioning guidelines.

So, I propose that we:

1. Revisit the versioning guidelines and come to agreement. Honestly, the only real difference between the two is the terminology (I used (published version).(major version) and @mrshirts used (published version).(major version).(minor version); I added some text about optional "tagging" for specific instances) and the "article timeline" example that I provided.
2. Make the github.io and article_template files consistent, for the time being, then revisit the content in both the template repo and the github.io site to decide which information needs to be where. Part of the problem is that information is duplicated in the two repos and we're struggling to keep them consistent.

Should we close this PR and take a step back, to fix one issue at a time? That was part of the problem with the issue tracker for versioning; I imported discussion about the class options to it and then mucked up the flow of ideas.

[mrshirts]

I had the impression that my proposal had endorsement of the managing editors and then proceeded accordingly.

Apologies, I was ambiguous on my "sounds good". I was assuming that it included all of the discussion previously.

All in all, though, I don't think that we are too far apart in the basic principles of the versioning guidelines.

Agreed.

Revisit the versioning guidelines and come to agreement. Honestly, the only real difference between the two is the terminology (I used (published version).(major version) and @mrshirts used (published version).(major version).(minor version); I added some text about optional "tagging" for specific instances) and the "article timeline" example that I provided.

I guess my instinct was to let people manage it by themselves, with a suggested. Instructing them to tag when the do increment the version is probably a good idea.

Part of the problem is that information is duplicated in the two repos and we're struggling to keep them consistent.

Right! My thinking (which is why I wasn't paying enough attention to the template repo) is that the templates should only give them instructions on how to do things in LaTeX in the document, i.e. how to change the versions if they want to. The instructions on what they should be doing in the first place (when to version, how to tag, how to get feedback from people) would be in the author instructions. That's what I'm imagining.

Should we close this PR and take a step back, to fix one issue at a time? That was part of the problem with the issue tracker for versioning; I imported discussion about the class options to it and then mucked up the flow of ideas.

Or just keep editing this PR, so it's all internally consistent instead of managing from multiple PRs.

[davidlmobley]

In terms of whether to repeat guidelines in the template repo that are also placed here -- I think it makes sense to have a bit of redundancy. If I'm just making a minor update to my article, it will save me a lot of time if I have some info on the versioning on hand in the templates I'm using rather than having to poke around on the website again to find it. (Could also be solved by having templates link to the right website page.)

[dwsideriusNIST]

How about a compromise inspired by @davidlmobley: put the descriptive information in the github.io site, but have a FAQ / "quick guide" in the template repo that is essentially a list of pointers to the github.io site?

As a stop-gap, I'm working on a minor revision to @mrshirts PR that will make it consistent with the template repo for the time being. Then we can plan the transferal of instructions from the template repo to the github.io site.

[dwsideriusNIST]

PR #184 updates this branch to be consistent with the template repo

[dmzuckerman]

How about a compromise inspired by @davidlmobley: put the descriptive information in the github.io site, but have a FAQ / "quick guide" in the template repo that is essentially a list of pointers to the github.io site?

I like this Dan S/David approach.

[mrshirts]

I have merged the stop-gap into this. Should I go ahead and merge this, or wait for your additional fixes @dwsideriusNIST?

[dwsideriusNIST]

@mrshirts I've made sufficient changes for the repos to be consistent in terms of content, so my recommendation is to merge this PR as is, then we'll start migrating / "uniformizing" the author guidelines.

[mrshirts]

Sounds good.