On Sun, Mar 31, 2013 at 6:03 AM, Sylvester Keil <[email protected]> wrote: > Why don't we just add the requirements (as well as those you mentioned below: > ordering, self-link etc.) to the tests? We can add a description and a link > to the schema to the Readme stating these as mandatory requirements for > pull-requests. GitHub will send each pull request and subsequent changes to > Travis-CI. We could even go further, by adding a Hook that auto-responds to > bad pull requests with a message reiterating the rules or something along > those lines.
A lot of style contributors are new to GitHub. Our instructions explain how to create new pull requests (which is relatively simple), but it's still rather complicated to modify an existing pull request via the website (basically, you have to navigate to the style file in the contributor's fork of the repo, in the branch used for the pull request; there the contributor can use the Edit button). I was hoping we could have contributors test as much as possible before creating a pull request, hence the stricter schema. > I have committed to many open source projects and typically, the more > established they are, the more burden is placed on the person making the > commit/pull request. Ideally, it should not be necessary for you (or other > maintainers) to have to respond to every pull request that leaves a style in > a bad shape, but only review those which pass all the repository rules. Yes. The style repo is rather unique though compared to many other open source projects in that we get a lot of one-off contributions from inexperienced users. Because of that I just think that the current method of manually creating pull requests isn't going to scale much further. I'm also wondering how many users simple decide not to bother submitting their style improvements because it's too much work. And, even if we have a process that only generates correct pull requests, the style repository maintainers will still need to review all the correct ones, which is going to be a significant burden if the repository gets even more popular. (see http://www.ohloh.net/p/CitationStyleLanguage for graphs that show the growth in the project activity) But maybe I'm asking the wrong question. To stir up the discussion a bit: developers who enjoy the availability of CSL styles (yes you!), be it from BibSonomy, colwiz, Docear, Drupal's biblio module, jekyll-scholar, KCite, Mendeley, pandoc, Qiqqa, or Zotero, what would you do if Sebastian and I stopped handling style submissions? So far, only Charles Parnot from Papers helps out. Do any of you have a process in mind that doesn't involve relying on me and Sebastian? :P > If I remember correctly, the tests validate each style against the schema; if > you can express the conditions, I can adapt some styles to be validated > against the new schema, as well. Some of the additional requirements in csl-repository.csl are already part of your test framework, but I'll look at the ones that aren't. Rintze ------------------------------------------------------------------------------ Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
