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
