request for comments

Another issue we need feedback on (though I think Rintze might explain
a bit more the rationale):

https://github.com/citation-style-language/schema/issues/53

My argument is for these sorts of changes, we really need to get
consensus from the entire implementer community. Please try to add
your two cents by end of next week, and we’ll see where we’re at.

Bruce

So basically the question is how we want to organize the process of
designing new CSL features and making modifications to the language.

One of the drawbacks of the existing CSL development workflow is that it’s
rather scattered. There is the xbiblio mailing list at SourceForge, several
active repos at GitHub (and inactive archive repos at SourceForge and
Bitbucket), the Zotero forums and the zotero-dev mailing list.

I know that Bruce and Frank follow mostly everything, but it’s a lot to keep
up with for outsiders. I was thinking that maybe I should be a bit more
aggressive with committing changes, prepare a changelog before a planned
release (we would need one anyway to document the changes for CSL style
authors and implementors), announce plans for release and have a few weeks
for reflection, and, after polishing things up based on feedback and
dropping problematic proposals, make a release.

Alternatively we could use our original approach of vetting issues
one-at-a-time. But this has proven to be rather slow as it’s difficult to
keep everybody’s attention to prolonged periods of time.

Rintze

Another issue we need feedback on (though I think Rintze might explain
a bit more the rationale):

https://github.com/citation-style-language/schema/issues/53

My argument is for these sorts of changes, we really need to get
consensus from the entire implementer community.

So basically the question is how we want to organize the process of
designing new CSL features and making modifications to the language.

One of the drawbacks of the existing CSL development workflow is that it’s
rather scattered. There is the xbiblio mailing list at SourceForge, several
active repos at GitHub (and inactive archive repos at SourceForge and
Bitbucket), the Zotero forums and the zotero-dev mailing list.

I know that Bruce and Frank follow mostly everything, but it’s a lot to keep
up with for outsiders. I was thinking that maybe I should be a bit more
aggressive with committing changes, prepare a changelog before a planned
release (we would need one anyway to document the changes for CSL style
authors and implementors), announce plans for release and have a few weeks
for reflection, and, after polishing things up based on feedback and
dropping problematic proposals, make a release.

Alternatively we could use our original approach of vetting issues
one-at-a-time. But this has proven to be rather slow as it’s difficult to
keep everybody’s attention to prolonged periods of time.

Rintze

So the idea is to have a more forward-leaning policy on commits? That
seems a good idea. We’re getting to a stage where changes are often
inter-related, and it can be cumbersome to discuss proposals in
isolation. Pre-release vetting would provide an opportunity for
focused review.

Frank

Maybe it would suffice to have a single development branch in each git repo
for such proposals (people other than Frank, Bruce and me can also just fork
if they want to create proposals). That way we wouldn’t create too much of a
mess in the main branch.

RintzeOn Tue, Jun 14, 2011 at 9:23 PM, Frank Bennett <@Frank_Bennett>wrote:

This post seems to be an influential discussion of an effective git
branching model.

http://nvie.com/posts/a-successful-git-branching-model/

See discussion of feature branches.

Git flow is based on this:

http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

It’s not exactly related to our use case, but perhaps close enough?

Bruce

So if we went this direction, it would suggest adding a main “develop” branch.

For new features, or major changes, one would then branch of
"develop"; e.g. “my-new-feature.”

When we all approve it (by whatever process we settle on), that code
gets merged back to “develop.”

… etc (see link above) …

This gives people flexibility to play with stuff all they want without
messing up the main schema code.

Bruce

OK, I created a “develop” branch on schema (and also on documentation,
but had some authentication issue when trying to push it).

Bruce