Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[David Hassell]

Just got my access permissions sorted out. 
https://github.com/cf-convention/cf-convention.github.io/pull/62 has been 
merged. Thanks

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-436711411

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[JonathanGregory]

Dear Chris et al.
David Hassell has now got permissions to merge pull requests. I believe this 
will be done soon, now he is able to do it (since a couple of days ago).
Cheers
Jonathan

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-436029898

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Chris Barker]

Can we close this now? not good to have lingering issues

I've started #150 -- where we can hash out the issues not addressed in the 
CONTRIBUTING.md doc





-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-435976027

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[David Blodgett]

Now that #137 is merged, I think we also need to merge: 
https://github.com/cf-convention/cf-convention.github.io/pull/62 right? Once 
that's done, I think this issue should be closed.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-430448618

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[JonathanGregory]

Dear all

That's very good. Thanks for proposing it, Dave.

David, would you be able to consider how and where to incorporate this in the 
governance page http://cfconventions.org/governance.html? Similarly, there is 
issue which Dave refers to about defects. How does these relate to trac ticket 
160 and have we decided to stop using trac for new tickets? We need some 
clarity, I would say, so that proposers of changes know how to proceed.

Best wishes

Jonathan


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-422445814

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[David Hassell]

Hello,

Three weeks have passed with no further discussion, so I think we can accept 
this issue - i.e. the new CONTRIBUTING.md file.

Very many thanks to everyone who gave their time and git experiences to this 
discussion on the mailing list, at the CF meeting in June and here on the 
github issue.

David

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-421917740

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[David Blodgett]

typos corrected.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-415978853

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[cameronsmith1]

It looks good to me.   I noticed a couple of typos:
+) In guideline 1, there is a 'tha' which should be 'that'.
+) In request 3, there is a 'their' which should be 'there'.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-415511243

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Chris Barker]

"I am assuming here that 'someone who wants to create a pull request' may 
actually want to create a rather complex change and work on it a little while 
with other folks"

I do that that is a significatn use case -- but whether that is a feature 
branch or a PR from a fork depends on involved someone with permissions on the 
repo is.

If an "outsider" starts a PR against master, the repo managers can choose to 
merge that into a feature branch instead of master if they want to develop it 
for a while before merging.

In short -- creation of a feature branch is the job of the core maintainers, so 
I'm not sure it needs to be mentioned in Contributing.md

Though maybe should be mentioned somewhere else as part of recommended workflow.




-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-413623385

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[John Graybeal]

Concurring with the entirety of this thread, the place you ended up has the 
advantage of being recognizable to any developer. With one possible exception, 
most developers are used to feature branches I think, and it would be nice to 
address this explicitly in some way, enough that someone who wants to start a 
feature branch can see what is expected and just do it.  (I am assuming here 
that 'someone who wants to create a pull request' may actually want to create a 
rather complex change and work on it a little while with other folks, and that 
this Contributing.md is where they would look to see how to do that too. If 
that's mistaken or likely to be rare, then never mind.)

John G




-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-413621548

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[cameronsmith1]

Removing 3 from Dave's list certainly makes it clean and simple.   The other 
issues can then be deferred until they are needed, per long-standing CF 
tradition.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-413292409

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[David Hassell]

There are clearly good reasons for making PRs against master, so I withdraw my 
suggestion of a using a branch.

I like 1, 2 and 4 of Dave's list 
(https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-412947016)
 but don't see the need for point 3: "branches are used as short and/or long 
term feature development space.". This, I think, is not relevant to creators of 
PRs so we don't need to mention it in this document.

The same seems true for the management of near release time - we don't need 
this in CONTRIBUTING.md because it won't affect contributors, who would carry 
on making PRs to master, regardless of the release mechanics being employed at 
the time.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-413121295

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[David Blodgett]

@cameronsmith1 -- my point on that was that I don't think any guidance we write 
now is going to be right. So we should use our best judgement on the workflow 
when we get there. I would rather not attempt to write rules for that stuff 
until we have more experience.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-413053296

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Chris Barker]

@cameronsmith1: good points.

I think the way to do it is to crate a "release candidate" branch when getting 
close.

-CHB
 

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-413025225

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[cameronsmith1]

We started using Github a few years ago for a project I work on. It was decided 
at the start that changes should go onto master frequently, and that we would 
simply tag master for the major release versions.   It didn't work in practice, 
because near release time there were divergent needs within the project.  Some 
people wanted to only allow changes to master that were for finalizing the 
release, while other people needed to keep working on future capabilities.  If 
finalizing the release only took a couple of weeks this wouldn't be a big deal, 
but big releases often takes months to finalize (CF tends to spend a lot of 
time agonizing over the details too).   I think this is the issue that 
@dblodgett-usgs mentioned in his last post (above).However, I don't see it 
explicitly mentioned in the 4 bullets.

There are two ways I can see this working near release time: (a) master is for 
the release version and future changes go onto one or more feature branches 
that get merged to master after the release, or (b) vice versa, ie the release 
on a branch and the master keeps developing.  In my project we ended up doing 
(b), but it would probably have been better to do (a).

In any event, I think it would be good to add a fifth bullet to the list of 
@dblodgett-usgs that clarifies how master and branches will be used near a 
release.




-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-413023840

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Chris Barker]

Sounds good -- and yes, this should go in CONTRIBUTING.md

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-412991644

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Chris Barker]

> There are already loads of branches within this repository, which can/will 
> lead to further confusion, 

Those look like "feature branches" -- which can be "pruned" once they are no 
longer needed.

https://railsware.com/blog/2014/08/11/git-housekeeping-tutorial-clean-up-outdated-branches-in-local-and-remote-repositories/

Note that if a branch has been merged, then pruning that branch doesn't lose 
any information in the history.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-412939772

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Chris Barker]

@hrajagers wrote:
>The branch per "release" approach might make it conceptually a little bit 
>easier to start working on a draft of "release 2.0" while also working on an 
>earlier "release 1.8".

Agreed -- master should be for the current "working version" -- i.e if 1.8 is 
out, changes that will be in 1.9 go in master.

In the usual case of software, you have a "current release", say 3.2 (choosing 
examples that aren't currently used for CF), and you are working on 3.3 in 
master.

Meanwhile, if you are maintaining older versions, say 3.1.3, you might do 
bug-fixes on that, and release a 3.1.4 -- in which case, there is a branch for 
3.1.* where the bug fixes go.

In the CF case, we don't have to fix bugs in older releases, so it's easier.

The one complication is if we have a "future" version that wont' be released 
for a while -- that would be 2.0 for CF -- so that should be in a separate 
branch -- or maybe a separate repo altogether.

I jsut took a look at the cPython repo -- for an exampel of a major project:

https://github.com/python/cpython

The currently have:

2.7
3.4
3.5
3.6
3.7
master

3.7 is the latest version -- they are working on 3.8 in master, and 2.7--3.6 
are in maintenance mode (i.e. just bug fixes).



-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-412938879

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[marqh]

i agree with @ChrisBarker-NOAA 


I am in favour of instructing contributors to propose all changes to `master` 
and tagging releases as they are created.

Branches are not required for managing the document in its normal work flow 
(though they may be useful for occasions such as  where an updated 'point 
release' is required to an existing release).
This is for administrators of the repository to manage, not for contributors to 
have to negotiate.

I think that managing branches for each 'next version' will cause maintenance 
problems and confusion for contributors.

There are already loads of branches within this repository, which can/will lead 
to further confusion, especially if we ask contributors to understand why these 
branches are there and which one to pick.

I recommend keeping the use of branches limited to repository administrators 
and pointing all contributions and contributors at `master`.

I also recommend ensuring that accepted changes are merged to master as soon as 
they are approved, so that further changes are being made with respect to the 
latest approved changes.

I am fairly clear on the benefits of this approach and concerned about the 
risks of pointing contributors at branches and holding off merging agreed 
changes to some future time.


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-412933788

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[marqh]

@davidhassell 

> An advantage of this over using master is that accepted issues can be merged 
> into the branch prior to release, and so be picked up by PRs for other, newer 
> issues.

Please can you elaborate on this statement?

It seems to me that it is fine to merge accepted issues onto `master`, that 
this should be the approach that is adopted.

What makes you make the statement that having an explicit branch for a next 
version allows merging accepted issues, suggesting that targeting `master` 
means that accepted changes would not be able to be merged?

thank you
mark

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-412903700

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[David Hassell]

Hello,

I'm back from leave. This is where I think we are with this discussion.

  * "Rules for correcting errors in CF documents" **[1]** and "Rules for CF 
Conventions Changes" **[2]** look good to me and have no outstanding comments.

  * "Contributing to the NetCDF-CF conventions" **[3]** is also looking good, 
but I wonder if we need to make note in this document of the issue that @erget 
raised: which branch should pull requests be created for?

I favour creating a branch for the next version (e.g. `1.8`) and specifying 
that pull requests be made to this branch. This branch would be created as a 
copy of the previous version (1.7) when that is released. An advantage of this 
over using `master` is that accepted issues can be merged into the branch prior 
to release, and so be picked up by PRs for other, newer issues. I don't have 
particularly strong views on this, though - on which branch nor whether this 
should be in the CONTRIBUTING.md document.

**[1]** 
https://github.com/cf-convention/cf-convention.github.io/pull/62/commits/e6f7747c8b94952651c567c9ffead9f74131080b?short_path=8f8a0b0#diff-8f8a0b09fa5f199438dd9e7557ce36db

**[2]** 
https://github.com/cf-convention/cf-convention.github.io/pull/62/files?short_path=91508a7#diff-91508a78c1f574c8c31da226cf3e7622

**[3]** 
https://github.com/cf-convention/cf-conventions/pull/137/files?short_path=8cc7b2b#diff-8cc7b2b0d78dd2501610391c086a8516

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-412887316

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[David Blodgett]

Dear Jonathan,

I've updated https://github.com/cf-convention/cf-convention.github.io/pull/62 
to include changes to errors.md.

I opened https://github.com/cf-convention/cf-conventions/issues/131 to deal 
with labels. My suggested changes are:  
Remove: `asciidoctor mod?`, `bug`, `invalid`, `simple`. 
Add: `typo`, `style`

OK, I'll wait for @davidhassell to summarize.

- Dave

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-411146561

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[David Blodgett]

Dear Jonathan, 

Actually, this text will end up in a "CONTRIBUTING.md" in this repository. It 
may also end up on the main web site. [This pull request 
](https://github.com/cf-convention/cf-convention.github.io/pull/62) likely 
needs some attention in light of the conversation here.

- Changed which to that.
- Yes, I think we should expect issues to be closed by practically all pull 
requests. I've modified the text.
- Yes, we should insist that those labels be used for **contributions.** Note 
that we may have labels for questions or other kinds of "issues".
- added: "as these changes do not appear in the convention history."
- Fixed type.
- Added "Note that their is a rendered "rich-diff" view of a pull request that 
can be helpful for review of large contributions."

I will get these changes checked in soon.

Best, 

- Dave

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-407176332

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Daniel Lee]

One thing we might wish to include in the contribution guidelines would be the 
branch which contributors should contribute to. As it is we say they should 
create an issue and a pull request which matches that issue, but there are some 
branch management issues which would have minor effects on this. If we have a 
branch for the next version of the convention, say `1.8`, should everybody base 
their branches off of there? Otherwise, if they're always branching off of 
`master`, there's the possibility that they'll fiddle with areas which will 
produce conflicts later, e.g. the author list or the version number.

Alternatively, we could say that the files which contain such common metadata 
related to the convention itself shouldn't be edited in a topical PR, but 
rather only be changed editorially in preparation for publishing a new version.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-406339131

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[David Blodgett]

Hi All,

This conversation has come quite a long ways. Glad to see that we are coming to 
some conclusions. 

I've done a bit of cleanup on the "CONTRIBUTING.md" document in the pull 
request mentioned above. Please comment and edit away. 

If we can work that text to finality, I think we just need to pick the timing 
of the switch over and put together the task list to get us there. Lots of food 
for thought about a task list above.

Best, 

Dave

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-406127192

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Daniel Neumann]

One minor comment on whether to run Trac and GitHub tickets in parallel or not: 
Most of us are registered at various web services and need to remember/save the 
login details for these services. Using Trac and GitHub in parallel for a long 
time period means for us to have two logins detail sets for cf-conventions 
tickets. One login set more or less isn't much -- but it sums up. Also we need 
to remember/save/bookmark two URLs for ticket system. Therefore, I would prefer 
a short transition phase. But that's my personal opinion.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-405601377

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[David Hassell]

Where I think we are on the outstanding questions:

  * **whether or not to run Trac in parallel for a while**

I suggest that, for new proposals, we do not run Trac and gihub for new 
proposal parallel. In practice this would mean:

1) We would set a date (that would presumably coincide with the acceptance 
of this ticket) after which new proposals must be made on github and no new 
proposals will be allowed on Trac. Discussions can continue on Trac until ...
2) We set another, later date, after which Trac will be turned off and its 
content archived. Any unfinished Trac discussions will be effectively closed. 
If there is still a will to continue a discussion then the proposal must be 
raised anew as a github issue proposal. (This is not as extreme as it first 
sounded to me - there are Trac tickets that have been open but haven't been 
posted to for over 10 years - these were never going to be resolved before Trac 
is turned off!)

  * **whether or not to create new github issues in the cf-conventions repo, 
the same repo as the copied Trac tickets, or yet another repo. [Whatever the 
answer, labels will be in use to help discern issues.]**

It seems that there is support for copying the existing Trac tickets to a 
new "archive" repository; but raising new proposals in the existing 
cf-conventions repository. New proposals can happily coexist with other issues 
(such as "should we use italics for example captions?") with the use of labels.

We would "fast-forward" the issue numbers in the cf-conventions repo so 
that new proposals would have different numbers to old ones - currently that 
means creating dummy issues up to and including nunber 174. This is important 
because if we didn't do this then our issue referencing could break in the 
future if we were to alter our change procedure yet again (such as if github 
were to ever fail to meet our needs). 

  * **whether or not to move the conformance document to the cf-conventions 
repo**

There is a compelling reason for moving the conformance document to the 
cf-conventions repository in that then there would only ever need to be one 
pull request per completed proposal. In the current situation (i.e. conformance 
in its own repo), some proposals will need two pull requests.

Thanks, David

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-404755429

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[David Hassell]

A summary of where I think we are:

There seems to be a consensus for:
  * The proposed 
[guidelines](https://github.com/dblodgett-usgs/cf-conventions/blob/CONTRIBUTING/.github/CONTRIBUTING.md)
  * A separate repository for the existing Trac tickets to be copied to issues
  * The appropriate use of issue labels 

I think that some more discussion is required for (perhaps some of these 
questions are nearly agreed):
  * whether or not to run Trac in parallel for a while
  * whether or not to create new github issues in the cf-conventions repo, the 
same repo as the copied Trac tickets, or yet another repo. [Whatever the 
answer, labels will be in use to help discern issues.]
  * whether or not to move the conformance document to the cf-conventions repo

I'm assuming that the discussion on how/when to merge completed proposals will 
be carried on in a different discussion, so we can move the original proposal 
of #130 to a faster conclusion.

Thanks, David

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-402871314

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Chris Barker]

On Thu, Jun 28, 2018 at 5:50 AM, JonathanGregory 
wrote:

> I agree with @rhattersley  that it would
> make sense to copy the trac tickets to a separate cf-conventions GitHub
> repository, with their original numbers, in order to keep them for
> posterity.
>
+1

> I don't think we should oblige everyone to switch immediately to GitHub
> and stop using Trac, though we can encourage it.
>
yes, we should -- having the same thing managed two ways is a pain in teh
#^$*.

I know change can be hard, but semi-change / lack of clarity, confusing
mess is harder.

And it's really not that different for the common use cases!

> The meeting last week was certainly in favor of a quick move, but the
> people at that meeting may not be an entirely representative sample of the
> whole community of contributors to CF. I guess it was a more technically
> minded set than the average.
>
maybe so -- but TRAC isn't exactly a model of usability :-) gitHub (at
least for issue management) isn't any more technical that TRAC, and I think
it's more usable, not less. So it's more a old dog / new tricks issue.

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-401089534

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[JonathanGregory]

Dear all

I agree with @rhattersley that it would make sense to copy the trac tickets to 
a separate cf-conventions GitHub repository, with their original numbers, in 
order to keep them for posterity. I don't think we should oblige everyone to 
switch immediately to GitHub and stop using Trac, though we can encourage it. 
The meeting last week was certainly in favour of a quick move, but the people 
at that meeting may not be an entirely representive sample of the whole 
community of contributors to CF. I guess it was a more technically minded set 
than the average.

We currently have three main repositories: the website, the conventions and the 
conformance document. I suggest that, for simplicity and unless it becomes 
inadequate, we could deal with governance issues in the website repository, 
because the gobernance rules are part of the website. This ticket ought to be 
in that repository, not this one, if you agree with this idea. I agree with 
@erget that it would make sense to merge the conformance and conventions 
repositories, since they have to be updated together. The data model will also 
belong with them.

I don't know how the mechanism works for sending these postings on issue to the 
CF email list. If this system can filter by label, we could follow what @erget 
and @rhattersley suggest to mark some of them as not to be distributed.

Best wishes

Jonathan

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-401023162

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Richard Hattersley]

As a general observation on the transition from Trac to Github, I would 
encourage embracing existing GitHub idioms to take advantage of the resulting 
simplicity. For example:

re: porting Trac issues to GitHub, I would recommend that you copy them to a 
separate repo dedicated to being an archive. That way the issue numbers can 
easily be preserved. If there's a need for new native GitHub issues to refer 
back to the Trac content, cross-repo links are still very easy, e.g. 
cf-convention/test-trac-convert#1.

re: conversations on "practical" vs "science" topis, I would recommend keeping 
all your issues and pull requests in the repo that they affect. Workflows 
across multiple repos are more complicated and error prone, and much less 
likely to receive any attention from GitHub. @erget's suggestion to take 
advantage of issue labels is a more natural fit. The use of issue labels is 
very common on GitHub.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-400936458

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Daniel Lee]

I think there could be some benefits for this, but yes, we'd need to update the 
contribution guidelines to be really clear. Perhaps the easiest thing to do 
would be to clone the cf-conventions repo and rename that so that topical pull 
requests / discussions go there, and then once things have been integrated on 
that side pull them across to e.g. this repo, which would be used for releases, 
including syntactical / editorial changes in order to keep the adocs up to 
date. As @dblodgett-usgs notes this would be easier for users wanting to only 
be involved in the content-related discussions.

For me this seems overly complex, but if the community really wants to be able 
to restrict spamming it could be a good way to go. Personally, I think the 
better alternative would be to post to different lists based on issue tags - 
I've heard of Hubot integrations which allow this, for example.

In that vein, I'd also be in favour of moving the Conformance into this repo, 
because that would make the workflow easier for ensuring that both the 
Conventions are updated simultaneously (I'm thinking of PR checks, as an 
example).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-400762846

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[taylor13]

Hi all,
I am told that PCMDI's maintenance of the Trac site here at LLNL is becoming 
more fragile for a number of technical reasons and our scarce resources to 
invest in it also make it problematic, so from a practical perspective our 
systems folks here would favor moving to github (although it is not imperative 
that this happen immediately).

Like others I am concerned about consistency of and/or conflicts between issue 
numbers associated with the Trac and github discussions.  If we renumber the 
trac issues won't it disrupt the cross-referencing already in those discussions?
Karl


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-400725543

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[David Blodgett]

Dear All, 

I would be supportive of a clean break from Trac -- and it's clear that there 
is a constituency in the community that would prefer that path. I think it is 
also clear that we are suggesting that outcome in the near future anyways, but 
potentially not an immediate retirement of Trac. While it may introduce a bit 
of confusion, my opinion is that confusion may be worth while to keep all 
community members engaged and be as inclusive as possible. At the end of the 
day, those of us that prefer using github need to demonstrate how to evolve the 
standard in github so those without experience in this environment can learn 
and join the :shipit: tribe. (I use the 
[squirrel](http://excid3.com/blog/finishing-is-all-that-matters) as an example 
of how foreign some github traditions and mechanisms really are.)

Is there any strong disagreement to this line of argument? My thinking is that 
we would continue to allow use of Trac until usage has dropped to near nill or 
maintenance of Trac is not worth the effort. Putting a timeline on this may not 
be worth the energy as it should happen naturally if this switch to github 
really is the thing to do.

I also think it would be a great idea to migrate the Trac history to a block of 
github issues. While the numbering would reset, we could embed the original 
Trac URLs in the issues for continuity. I think this would naturally occur at 
the time that we retire our use of Trac.

Best, 

Dave

p.s. I would like to remind everyone that while we have moved some of our 
discourse to github, I think we should attempt to maintain the traditions of CF 
in our correspondence. Each of these comments fires off an email to the group 
and, as such, should be thoughtful and worthy of people's attention if at all 
possible.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-400711387

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Sebastien]

1mn googling: https://github.com/mavam/trac-hub

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-400702880

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Sebastien]

why not simply import all past TRAC tickets and convert them into github 
issues? 
I am sure we can find that kind of scripts, possibly in a github repo!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-400702431

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Chris Barker]

So all ticket numbers below 200 belong to Trac; above 200 to GitHub.

+1


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-400701342

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Aleksandar Jelenak]

It is manageable only with additional context, for example: `Trac #101` or `GH 
#101`.

Alternatively, GitHub's API can be used to create and close dummy issues until 
the internal numbering is bumped up above the highest ticket number on Trac. Or 
go all the way to, say, 200. So all ticket numbers below 200 belong to Trac; 
above 200 to GitHub.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-400659078

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[David Hassell]

I have a concern with the hybrid github/trac approach: Some github issue 
numbers are/will be the same as Trac ticket numbers. 

Is this managable?

David

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-400410862

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[JonathanGregory]

Dear all

As David H says, I think we should first decide the procedure for making 
decisions on changes using GitHub (as an alternative to Trac). This will be 
part of a modified version of http://cfconventions.org/rules.html, so at this 
point we need explicit text to put in that document. In principle it should be 
the same procedure as now regarding the time-limits etc.

One change in the procedure could be to recognise an extra kind of change 
request i.e. typo, which is different from defect or enhancement. A defect is a 
proposal to change the words of the document to correct an error or clarify 
them, with materially changing the meaning of it. Someone else might disagree 
with the proposer of a defect ticket and think what they propose is actually a 
material change to the meaning, and in that case the proposal has to be 
discussed as an enhancement instead i.e. not accepted by default. A typo is an 
even more minor change which fixes something that seems evidently to be simply 
a mistake. However it's possible, in an analogous way, that someone else might 
say that it's not a typo, but deliberate, in which case it'd have to be 
discussed as a defect or enhancement instead.

I think that a typo could be proposed with a pull request, but a defect or an 
enhancement should be started with an issue, as David H says, and proceed to a 
pull request when it's fairly well agreed and it comes to a matter of wording.

Cheers

Jonathan


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-399946778

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[David Hassell]

I think that we have to be very clear this is a proposal for how github issues 
can replace Trac tickets (as opposed to anything else we currently use, like 
the mailing list) and, at the this time at least, nothing else. This issue is 
concerned with how best to use github to carry this out in a way that make 
sense to people now, and in 20 years time.

In particular, github issues are only for completely defined proposals, not for 
any sort of speculative change; and all proposals must be raised as an issue 
(although that could coincide with a pull request for simple cases, e.g. typos).

The discussion has widened a bit to include "how should we integrate accepted 
proposals into CF", which is fine, but this is a separate concern to the 
original "how should we get a proposal accepted". These two are certainly 
connected, but will need quite distinct guidelines.


The [original proposal](#130) contains guidelines that I think say

1.  Start by using a github issue just as you would a Trac ticket
2. ...
3.  When it is finished there will be a pull request

How we get from 1. to 3. is less clear to me, but that will be resolved by the 
discussions in this issue.

When I come back in 2038, I need to be able to start at the top of #130 and be 
able to follow the arguments that led to its conclusion. Linking out to pull 
requests as part of this read through is fine by me, although I have a concern 
about searching - if I search for "foobar" in the issue, will it also search 
for that string in all referenced pull requests? This was also an issue for 
documents attached to/linked form Trac tickets, but the reality was that they 
were very rarely used, and if they were it was not for essential items such as 
proposed text changes.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-399863132

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Daniel Lee]

I don't feel strongly about how we do branches and since I'm the only one 
currently supporting having a `next` branch on here that's fine with me. I 
think the release frequency is something which should be discussed more widely, 
but it's independent of our workflow for producing releases.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-399676789

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Chris Barker]

I agree with @ajelenak-thg and @marqh  here -- I don't see a utility in having 
a next branch.

In general, master is supposed to be the "lastest" version, not ready for 
release yet.

As for "CF isn't software that we're releasing with continuous delivery, having 
fewer, but larger, changes between versions is probably the better way to go."

I'm not sure that it makes much difference how many changes there are between 
versions. Also -- maybe we should move to a more continuous delivery model -- 
why nothve point releases that have clarifications and typos corrected?

What we should do is be sure to crate a branch for significant changes or 
additions, then they can be fully developed in that branch until ready for 
merging into master.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-399480412

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[marqh]

I think that the people who are new to github will appreciate a lack of 
complication in the structure of information and how to engage.

Having a single branch makes is clear to anyone arriving that if they want to 
propose a change, that is what their change is with respect to.

So, I am in favour of maintaining the `master` as the editor's draft and 
providing tags for released versions and against a `next` branch.

I have also proposed a change to the CF website that makes the current state a 
little more clear: 
https://github.com/cf-convention/cf-convention.github.io/pull/61




-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-399387161

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Daniel Lee]

This is definitely the most natural way to work on GitHub and very git-native, 
which I like. However, I do think there is merit in having a `next` branch. 
Because CF isn't software that we're releasing with continuous delivery, having 
fewer, but larger, changes between versions is probably the better way to go. 
It also better reflects the understanding achieved at the meeting - namely, 
that `master` is basically a release branch, and that the draft (whether named 
`next` or something else) collects changes before merging them all into 
`master`.

Concerning the workflow @ajelenak-thg outlines - that's certainly the way I 
intend to work, but my feeling is that we'll perhaps need to have a bit of 
patience with people who are new to both git and GitHub as they get used to it, 
so we shouldn't be too strict with enforcing the specifics of that workflow.

So the only point of ambiguity for me is the branches. I do think that having 
`master` only be merges with tagged releases has advantages for novices - even 
though you can achieve the same amount of traceability by only tagging 
releases, and declaring intermediate commits on `master` as transitionary, I 
think that having non-tagged releases appear as the repo's landing page could 
be confusing to some of our contributors.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-399350001

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[David Blodgett]

I % agree with @ajelenak-thg. 

I think this is more or less how the repository works now and this is a very 
natural pattern.  Released tags would get built and stored as binaries here: 
https://github.com/cf-convention/cf-conventions/releases as well as on the main 
cf web page.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-399212856

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Aleksandar Jelenak]

>I propose something inspired by Git Flow, roughly as follows:
>master is the current release.
>next is the next release, an "editor's draft", if you will.

I don't think we need a `next` branch. Each new convention version will be a 
tagged release in the master branch thus allowing this branch to represent the 
Editor's Draft. All the new material merged into the master branch after the 
last release is assumed to be accepted for the next release, barring any 
stylistic or formatting changes.

The process would go something like this:

1. Anyone who wants to propose a change to the convention should fork this 
repository. (I assume the number of those with commit privileges will be small 
so forking is what majority will have to do.)

1. Create a branch off the master in the forked repository and work on the 
proposed changes in this new branch.

1. Creating a pull request to the upstream (the official convention's) 
repository initiates the formal review process of the proposed changes.

1. Pull request creator is responsible for updating its branch and the text of 
the changes with the upstream's master branch during the review process.

1. The review process ends when the pull request branch is merged into the 
upstream's `master` branch.

It would be good to appoint, at least nominally, a few editors for every new 
convention release. They would be in charge of preparing the text in the master 
branch for the next release and making sure the review process of any open pull 
request is reasonably timely.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-399197009

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[cameronsmith1]

This seems reasonable to me.  I would expect that some active management may be 
needed in the run-up to a new release, ie managing which PRs get merged or held 
until after the release.  However, that shouldn't affect your general outline.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-398845859

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Daniel Lee]

I agree with the discussion wholeheartedly, which for the sake of keeping 
things tidy and confirming my own understanding I summarize as follows:
- If you want to change something and are in doubt, raise an issue
- For anything else, a PR is a good way to go, although an issue isn't harmful, 
especially if it's about a typographical matter
- What I'm missing is a release strategy, which may need to be addressed 
elsewhere. I propose something inspired by Git Flow, roughly as follows:
  - `master` is the current release.
  - `next` is the next release, an "editor's draft", if you will.
  - If you want to make a change, make a branch based on `next` and implement 
it. Then send a PR to merge it back into `next` or ask for help.
  - When a change has been approved, it's merged into `next`.
  - When we make a release, we merge `next` into `master` and tag that.

Perhaps more refinement is possible - we discussed at the meeting having some 
kind of a beta version of a next release for a time. This would be compatible 
with this workflow (which is one of many possible ones, but fairly simple and 
IMHO straightforward).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-398843638

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[David Blodgett]

Dear all,

Apologies for going mute for a bit. Apparently, my email overlords (bow to the 
security gods) decided that github notifications are spam -- amazing how you 
don't miss notifications when they are gone.

I 100% agree that an external document is an imperfect solution that is really 
only suited to pre-community-review draft development. 

I also agree that we should have issue 
["labels"](https://github.com/cf-convention/cf-conventions/labels) to 
`enhancement`, `defect`, and `typo`.  I will add a note that labels should be 
used if at all possible to the guidelines.

Yes, @davidhassell -- sounds great to have you moderate.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-395398572

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Chris Barker]

@dblodgett-usgs wrote:

> I hope that in the future, we have a nice interface for diffing, commenting, 
> and evolving text for this kind of application, but right now we just don't. 
> So we need to kick out to google docs or fork repositories in small groups to 
> evolve the text of major contributions and look to the future for better 
> solutions.

Frankly, gitHub PRs are a pretty darn good interface for "diffing, commenting, 
and evolving text" it does fall down a bit on a having a good way to comment on 
an existing doc, rather than just the diff, but not too bad.

"kick out to google docs" (or anything else) is a bad idea -- the whole point 
of git is to preserve the history, that's the part we really want to keep.

However, key is that we need to start with a policy, and then see how it goes 
-- frankly, we can't nail down an exact policy anyway, and people wouldn't 
exactly follow it if we did.

But in short, my suggestion is: 

- Use gitHub issues for managing general discussion

- Use gitHub PRs for proposing and discusing changes to the text of the 
document.

- Use branches when there is a large change, particularly if it effects 
multiple parts of the doc.

- Use whatever the heck you want to develop the first draft of a major addition.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-393207022

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[Chris Barker]

I agree with what has been said about googledocs, but we should remember
that they are not, at present, universally accessible and so we should
always have alternatives.

A google doc is also essentially ephemeral— it is not a good place to
record history, or the ability to roll back changes, etc.

We should use git+gitHub for what it is good for.

Granted, these are tools designed for code, not text documents, but when
you are working with a plain text markup language, they really do work
well.

In fact, being able to use them with a version control system is one of the
primary motivations to using text-based markup.

The CF standard is a pretty mature document. Most of the changes will be
small, and well suited to the “diff” based approach of gitHub.

So we should use gitHub for those changes.

Occasionally we may have a large new feature ( like the recent geometries
one ). If the primary authors of such a section find it more productive to
develop the first draft in google docs (or whatever they want), fine. But
it should go into a PR once there is a draft proposal.

-CHB


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-393192061

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[David Hassell]

I would be very happy to act as moderator, if that OK with you, Dave?

Adding a label to an issue is easy and should go into the 
[guidelines](https://github.com/dblodgett-usgs/cf-conventions/blob/CONTRIBUTING/.github/CONTRIBUTING.md).

I agree with what has been said about googledocs, but we should remember that 
they are not, at present, universally accessible and so we should always have 
alternatives.

David

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-393140087

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[JonathanGregory]

Dear Dave

Thanks for your contributions. I could be moderator of this, and thank you for
asking, but if David Hassell has time to do so that might be better since I'm 
rather short of time at present. Would you, David?

I agree with you that a googledoc is a good medium for editing large amounts of
text (in the mode where edits are suggestions). Maybe some comments could be
added about this possibility. There is a need to keep intermediate versions, I
would say, as the issue proceeds to discuss them. If there is only one evolving
doc it's not so easy to compare successive or alternative versions.

We should preserve the distinction between enhancements and defects that we
currently have with the trac tickets. Perhaps pure typos could be identified
as a separate category from these.

CF doesn't currently have a code of conduct but I agree it's a good idea to
adopt one. That's a governance issue, I think. I wonder what Karl feels.

Best wishes

Jonathan

On Mon, May 21, 2018 at 12:35:43PM -0700, David Blodgett wrote:
> Date: Mon, 21 May 2018 12:35:43 -0700
> From: David Blodgett 
> To: cf-convention/cf-conventions 
> Cc: JonathanGregory , Mention
>  
> Subject: Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines
>  (#130)
> 
> Dear CF community, 
> 
> I've started work on #130. It can be seen in pull request form between 
> branches in my fork 
> [here](https://github.com/dblodgett-usgs/cf-conventions/pull/10/files) or in 
> rendered markdown form 
> [here](https://github.com/dblodgett-usgs/cf-conventions/blob/CONTRIBUTING/.github/CONTRIBUTING.md)
>  
> 
> @ChrisBarker-NOAA -- I did not get all your ideas implemented. If you want to 
> leave comments with proposed additional details or ideas for an additional 
> section, I'm happy to copy/paste/rewrite, I just didn't really know how to 
> fit your thoughts into the doc at the first pass.
> 
> Others, please don't hesitate to leave in-line comments on the pull request 
> version, but please do also summarize your comments in line in this issue so 
> they make it to the email list.
> 
> Note that I also added the [Contributors 
> Covenant](https://github.com/dblodgett-usgs/cf-conventions/blob/CONTRIBUTING/CODE_OF_CONDUCT.md)
>  as a placeholder for a code of conduct. Is there a pre-existing CF code of 
> conduct written down some where?
> 
> @JonathanGregory -- do you want to act as moderator of this discussion? I 
> think it would be in our interest to move it to near conclusion prior to the 
> meeting in June. 
> 
> Best regards,
> 
> Dave
> 
> p.s. apologies for the push of a couple commits to #115 that came over the 
> email list a moment ago -- Those commits were promptly reverted and moved to 
> another branch.
> 
> -- 
> You are receiving this because you were mentioned.
> Reply to this email directly or view it on GitHub:
> https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-39075


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-392906937

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[David Blodgett]

Dear CF community, 

I've started work on #130. It can be seen in pull request form between branches 
in my fork 
[here](https://github.com/dblodgett-usgs/cf-conventions/pull/10/files) or in 
rendered markdown form 
[here](https://github.com/dblodgett-usgs/cf-conventions/blob/CONTRIBUTING/.github/CONTRIBUTING.md)
 

@ChrisBarker-NOAA -- I did not get all your ideas implemented. If you want to 
leave comments with proposed additional details or ideas for an additional 
section, I'm happy to copy/paste/rewrite, I just didn't really know how to fit 
your thoughts into the doc at the first pass.

Others, please don't hesitate to leave in-line comments on the pull request 
version, but please do also summarize your comments in line in this issue so 
they make it to the email list.

Note that I also added the [Contributors 
Covenant](https://github.com/dblodgett-usgs/cf-conventions/blob/CONTRIBUTING/CODE_OF_CONDUCT.md)
 as a placeholder for a code of conduct. Is there a pre-existing CF code of 
conduct written down some where?

@JonathanGregory -- do you want to act as moderator of this discussion? I think 
it would be in our interest to move it to near conclusion prior to the meeting 
in June. 

Best regards,

Dave

p.s. apologies for the push of a couple commits to #115 that came over the 
email list a moment ago -- Those commits were promptly reverted and moved to 
another branch.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-39075

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[John Graybeal]

Thank you Dave!

Well captured Chris, I concur. (And even for people who are newbies this could 
be a nice gentle introduction to Pull Requests!) 

I may be misremembering, but I thought that given the right configuration, text 
files in GitHub can actually be 'edited in line' and submitted as a pull 
request. (I do know that if you have enough privileges you can edit in line and 
have the results merged straightaway, but for sure that's not what we're doing 
in this case.) That could be a nice path to describe for people, if true.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-383175251

Re: [cf-convention/cf-conventions] GitHub Contribution Guidelines (#130)

[JonathanGregory]

Thanks for starting this, Dave. I'm grateful to you for taking it on - it think 
it will be very useful. Since you've already included all my comments (!) I 
don't have any more to make just now. I hope others do. Jonathan

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-382779429