On Mon, Jul 4, 2011 at 10:21 AM, Bruce D'Arcus <[email protected]> wrote:
> 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.
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>
>
> ... 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
> >
>
> 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
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
xbiblio-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
