# development process

**URL:** <https://discourse.citationstyles.org/t/development-process/1025>\
**Category:** CSL Development\
**Created:** [July 4, 2011, 2:21pm UTC](https://discourse.citationstyles.org/t/development-process/1025 "2011-07-04T14:21:39Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [July 4, 2011, 2:21pm UTC](https://discourse.citationstyles.org/t/development-process/1025/1 "2011-07-04T14:21:39Z")

</div>

I’ve been prompted to think about CSL development process again, but two things:

1. Rintze issued a pull request and I accepted it too quickly. But  
what should be the proper process? What’s the appropriate time-frame?  
How do we deal with dissent? Also, I think in general Rintze has been  
a little frustrated with the not-entirely fluid process.

2. some tension in the Sakai world around OAE development process, in  
which Ian Boston advocated for the Apache model

So I looked at the Apache model:

[https://blogs.apache.org/comdev/entry/how\_apache\_projects\_use\_consensus](https://blogs.apache.org/comdev/entry/how_apache_projects_use_consensus)

… and want to ask what we should do?

I floated one idea (which is basically to use github pull requests +  
Apache model for spec or schema change proposals) here:

[https://github.com/citation-style-language/documentation/pull/18#issuecomment-1493667](https://github.com/citation-style-language/documentation/pull/18#issuecomment-1493667)

So in other words, pull requests require concrete proposals (though we  
have the problem they may be split across two projects,  
unfortunately), and the Apache process (essentially, any member has a  
veto right, and we have an explicit focus on consensus) makes sure  
we’re on the same page.

Bruce

---

<div class="post-metadata">

**Author:** ![Rintze\_Zelle](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/rintze_zelle/32/175_2.png) [@Rintze\_Zelle](https://discourse.citationstyles.org/u/Rintze_Zelle)\
**Post date:** [July 4, 2011, 3:35pm UTC](https://discourse.citationstyles.org/t/development-process/1025/2 "2011-07-04T15:35:24Z")

</div>

> I’ve been prompted to think about CSL development process again, but two  
> things:
> 
> 1. Rintze issued a pull request and I accepted it too quickly. But  
> what should be the proper process? What’s the appropriate time-frame?  
> How do we deal with dissent? Also, I think in general Rintze has been  
> a little frustrated with the not-entirely fluid process.

I’m not frustrated. I think pull requests can be handy for discussing schema  
and spec changes. It even allows for collaborative editing (all that is  
needed is for me to give commit rights to my fork; any additional commits in  
the feature branches will appear in my pull requests). It’s just rather  
unhandy that it’s currently impossible to link pull requests to existing  
issues. I think things should work fine if: a) I clearly link pull requests  
to any existing relevant issues, and b) the other main CSL contributors  
indicate approval or disapproval of the changes in the pull request. It  
would be great if pull requests can be reviewed within about two weeks, to  
keep some pace of development.

As for dissent: it has proven to be difficult to get timely feedback from  
all parties involved in CSL. So again, to keep things moving I think I  
should take the liberty of being slightly aggressive in making commits. I’m  
always open to feedback, and there’s plenty time before releases to reflect  
on things. I’m planning to maintain a changelog with (proposed) CSL 1.0.1  
changes so everybody can more easily keep track of things. I’m fine with  
vetoing power for all, assuming they can support their case.

1. some tension in the Sakai world around OAE development process, in

> which Ian Boston advocated for the Apache model
> 
> So I looked at the Apache model:
> 
> [https://blogs.apache.org/comdev/entry/how\_apache\_projects\_use\_consensus](https://blogs.apache.org/comdev/entry/how_apache_projects_use_consensus)
> 
> … and want to ask what we should do?
> 
> I floated one idea (which is basically to use github pull requests +  
> Apache model for spec or schema change proposals) here:
> 
> \<  
> [Add cite-group-delimiter attribute, discuss cite grouping and be more spe by rmzelle · Pull Request #18 · citation-style-language/documentation · GitHub](https://github.com/citation-style-language/documentation/pull/18#issuecomment-1493667)
> 
> > 
> 
> So in other words, pull requests require concrete proposals (though we  
> have the problem they may be split across two projects,  
> unfortunately), and the Apache process (essentially, any member has a  
> veto right, and we have an explicit focus on consensus) makes sure  
> we’re on the same page.

Yes, I’m wondering if there would be an easier way to discuss CSL changes.  
In the old days, we mostly relied on the xbiblio list. Now, we have the  
xbiblio list, the Bitbucket citeproc-test, and 5 Github CSL repos, all with  
their respective issue trackers. That’s not much of a problem for me, but I  
can imagine it looks rather unorganized for outsiders.

Rintze

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [July 4, 2011, 3:51pm UTC](https://discourse.citationstyles.org/t/development-process/1025/3 "2011-07-04T15:51:37Z")

</div>

> > I’ve been prompted to think about CSL development process again, but two things:
> > 
> > 1. Rintze issued a pull request and I accepted it too quickly. But  
> > what should be the proper process? What’s the appropriate time-frame?  
> > How do we deal with dissent? Also, I think in general Rintze has been  
> > a little frustrated with the not-entirely fluid process.
> 
> I’m not frustrated. I think pull requests can be handy for discussing schema and spec changes. It even allows for collaborative editing (all that is needed is for me to give commit rights to my fork; any additional commits in the feature branches will appear in my pull requests). It’s just rather unhandy that it’s currently impossible to link pull requests to existing issues. I think things should work fine if: a) I clearly link pull requests to any existing relevant issues, and b) the other main CSL contributors indicate approval or disapproval of the changes in the pull request. It would be great if pull requests can be reviewed within about two weeks, to keep some pace of development.

Quick search says while one can’t currently attach a pull request to  
an existing issue in the UI, one can do it via the API:

[http://goldendict.org/forum/viewtopic.php?f=6&t=1153](http://goldendict.org/forum/viewtopic.php?f=6&t=1153)

> As for dissent: it has proven to be difficult to get timely feedback from all parties involved in CSL. So again, to keep things moving I think I should take the liberty of being slightly aggressive in making commits. I’m always open to feedback, and there’s plenty time before releases to reflect on things. I’m planning to maintain a changelog with (proposed) CSL 1.0.1 changes so everybody can more easily keep track of things. I’m fine with vetoing power for all, assuming they can support their case.

What would be the precise workflow, then? Would these changes be  
maintained on a branch? How would you roll back a specific changes two  
months after the fact?

Do we want to formalize some standard time-frame for feedback?

> > 1. some tension in the Sakai world around OAE development process, in  
> > which Ian Boston advocated for the Apache model
> > 
> > So I looked at the Apache model:
> > 
> > [https://blogs.apache.org/comdev/entry/how\_apache\_projects\_use\_consensus](https://blogs.apache.org/comdev/entry/how_apache_projects_use_consensus)
> > 
> > … and want to ask what we should do?
> > 
> > I floated one idea (which is basically to use github pull requests +  
> > Apache model for spec or schema change proposals) here:
> > 
> > [https://github.com/citation-style-language/documentation/pull/18#issuecomment-1493667](https://github.com/citation-style-language/documentation/pull/18#issuecomment-1493667)
> > 
> > So in other words, pull requests require concrete proposals (though we  
> > have the problem they may be split across two projects,  
> > unfortunately), and the Apache process (essentially, any member has a  
> > veto right, and we have an explicit focus on consensus) makes sure  
> > we’re on the same page.
> 
> Yes, I’m wondering if there would be an easier way to discuss CSL changes. In the old days, we mostly relied on the xbiblio list. Now, we have the xbiblio list, the Bitbucket citeproc-test, and 5 Github CSL repos, all with their respective issue trackers. That’s not much of a problem for me, but I can imagine it looks rather unorganized for outsiders.

To me, the biggest problem is (in hindsight) is the split between  
schema, spec, tests. But I don’t know what to do about it now.

What I think we basically need is a process that is a) a little more  
transparent and clear, and b) more easily self-sustaining.

Bruce

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [July 4, 2011, 4:04pm UTC](https://discourse.citationstyles.org/t/development-process/1025/4 "2011-07-04T16:04:59Z")

</div>

See also:

[http://stackoverflow.com/questions/4528869/how-do-you-attach-a-new-pull-request-to-an-existing-issue-on-github](http://stackoverflow.com/questions/4528869/how-do-you-attach-a-new-pull-request-to-an-existing-issue-on-github)

Bruce

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [September 3, 2011, 4:28pm UTC](https://discourse.citationstyles.org/t/development-process/1025/5 "2011-09-03T16:28:48Z")

</div>

I’d like to resurrect this thread, which failed to get any feedback  
from the broader development community.

It’s prompted by the fact that I have just felt compelled formally  
objected to a patch that Rintze made.

[https://github.com/citation-style-language/schema/issues/50](https://github.com/citation-style-language/schema/issues/50)

In my view, this should require the patch be rolled back, and that  
anyone on this list has the authority to similarly object to changes.

If we’re not going to adopt such a process, then I think we’re heading  
for trouble.

Bruce

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [September 3, 2011, 4:58pm UTC](https://discourse.citationstyles.org/t/development-process/1025/6 "2011-09-03T16:58:58Z")

</div>

And to give you an idea of details, here’s a general description of  
the apache voting process:

[http://www.apache.org/foundation/voting.html](http://www.apache.org/foundation/voting.html)

… and an example closer to CSL, of a recent specification:

[http://groups.google.com/group/opensocial-and-gadgets-spec/browse\_thread/thread/4759a30ed73c5af8#](http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/4759a30ed73c5af8#)

So in this case, they open up a formal voting process for a specific  
release (OpenSocial 2.0) against a specific revision with a list of  
patches, open for a defined time-period. People signed up with voting  
rights vote.

Note also there are different kinds of votes. The standard one (for  
more important changes I guess) require at least three +1 votes. The  
lazy-consensus vote has a lower-bar.

We essentially need to make the revision process for CSL as  
easy-as-possible to manage (technically and socially), but also one  
that leads to predictability for development.

If anyone has any particular ideas of how to best operationalize this  
for CSL, I’d like to hear them.

I suggested to Rintze, for example, that one possibility after 1.01 is  
to merge some of the repos so that patches can be more easily  
identified and isolated. Perhaps a new feature, then, would have a  
feature branch, and we could periodically collect a few to vote on,  
maybe some with lazy voting, and others with a higher-bar?

Bruce