I agree that with all the styles now in the repository, getting stricter is the way to go, and aiming for quality should be the goal. Being less friendly with the pull requests and asking more from the contributors is maybe unfortunate but the only sustainable way IMO.
The fact that most of the work is done by unpaid contributors is a real concern, and Rintze asks a very good question. Interestingly, and maybe it's going to be a surprise, but I am not paid by Papers/Springer. I just continue on the side to work on some of the CSL stuff, but it's really a side activity. I have a direct contact with the Papers people, and we receive a lot of useful feedback on issues with some styles, but we don't have the resources to answer them all at the moment. We hope to have someone with more time on his hands to dedicate to this, though at the moment, there is no promise on that. One of the reasons I keep working on this, is that I am personally excited by the project and its achievements. I want CSL to become the de facto standard. The idea of a grant is a great one. The project has reached a level of maturity that makes it a good candidate for that. If the project received a grant, of say $100,000, the way I would like it to be spent is to pay one person for 1-2 years to devote 100% of her/his time to writing new styles, and correcting existing ones. I am pretty sure the Papers guys would be perfectly happy to send all the feedback we have to this person :-) Charles On Mar 31, 2013, at 8:59 PM, Sebastian Karcher <[email protected]> wrote: > Hi, > > > 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. > I think Sylvester and Rintze's approach are really 2nd and 1st best solutions > to the current problem. > If we can find a way to make style submissions easier and more reliably > correct that would be ideal. I see some issues - e.g. the fact that we seem > to get people to correctly name styles (even though e.g. the visual editor > mostly does that right by itself), to include ISSNs and links to style guides > - that I wouldn't really know how to automate. Also, things like checking > whether a style should be a dependent style seems relatively hard to > automate, but I'm not an expert on automation and it's very well possible > that I'm underestimating what can be done. > > But if we can't get this to work, I think the only sustainable way to go is > to do what Sylvester says and increase the burden on contributors. I'm less > apprehensive about that than Rintze. The majority of pull requests we get > that require a lot of attention is for new styles. I'd argue that - while > it's obviously good to cover as many styles as possible - we now have so many > styles that my main concern would be to improve their quality rather than > their quantity. (that includes outright mistakes - styles not conforming to > their style guides, incomplete styles that don't cover all commonly used item > types (not all styles need to cover, say, legal cases, but most should > probably cover theses and reports), as well as things like poor coding of > affixes that lead to incorrect output on certain data constellation and > requires, as Andrea has pointed, a fair amount of processor work-arounds that > aren't actually part of the specs.) > > 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) > > right - and I don't see any way around that, so this: > > > 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 > > really does strike me as a rather important question. For me, the problem > isn't just that dealing with erroneous pull requests is a lot of unpaid work, > but also that it's not exactly exciting and quite repetitive for the most > part (e.g. I mind much less looking over correct pull requests to improve the > code). > > > Shifting to more near term solutions: > I think stricter Travis conditions are a good idea. > The other thing I'd like to see - and I assume that's possible - is that a > failing Travis would automatically lead to a message along the lines of what > we're writing manually now: > "Thank you for your submission to the citation-styles repository. > Unfortunately, our friendly maintenance-bot Travis tells us that there are > some problems with you submission. Please make sure that you've followed all > the style requirements [link]. Travis's output [link] may give you additional > clues about the problems in your submission." > > Happy egg (or afikomen) hunting: > Sebastian > > > -- > Sebastian Karcher > Ph.D. Candidate > Department of Political Science > Northwestern University > ------------------------------------------------------------------------------ > 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 -- Charles Parnot [email protected] twitter: @cparnot http://mekentosj.com ------------------------------------------------------------------------------ Own the Future-Intel® 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://p.sf.net/sfu/intel_levelupd2d _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
