On Mon, Jul 4, 2011 at 11:35 AM, Rintze Zelle <[email protected]> wrote: > > 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.
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 > 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? >> 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. 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 ------------------------------------------------------------------------------ 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
