On Apr 1, 2013, at 10:39 PM, Sebastian Karcher wrote: > I think a style editor and someone in charge of maintaining styles serve two > different purposes. The style editor is very useful for people to identify > the styles they want and it's great to allow them to make small > alterations/customizations. Since we don't accept any style to the > repository, I think that's quite valuable and I'm very glad we have the > editor around. > > But I completely agree with Charles that the style editor won't solve the > quality problem. Two reasons: 1. People without experience are less attuned > to details in styles - even the librarians I trained for Zotero often missed > small details. 2. As soon as you make larger changes, inexperienced users > write bad CSL, be it with the editor or without. (In particular they use > affixes instead of groups way too much).
I fully understand Rintze's hesitation where putting more responsibility into the hands of contributors is concerned; after all, these are individuals who have already made an effort to help: they created a pull request – now, obviously, we don't want to scare them away by adding too many obstacles; at the same time, however, I believe the style repository has (as Rintze illustrates) become such an asset by now, that you can take the liberty to be a little stricter. The salient point is that the rules must be well documented and that we do help and support contributors as best we can – but I think all contributors are aware of the quality they're getting from the style repository and will understand the little extra effort involved in becoming contributors themselves. So, as I've said before, I'll gladly add more rules to the tests for them to be enforced automatically. Ultimately, we could combine this with style-level tests – travis ci supports node and haskell so we could process test data with the open source cite processors. All of this, though, does not replace the work of repository maintainers like Rintze or Sebastian; these are just ways to make their work more efficient and effective. > I think fixing existing styles may take up less work than Charles suggest - > I think 10 a day isn't unrealistic. This is probably too low-tech for a > google-summer project, is it? Sylvester, any thoughts? I've been thinking about that, too. You're right that fixing styles is probably not sufficiently challenging, but we've already mentioned lots of ideas on this list which would make for good summer of code projects. It's too late to work on an application now, but perhaps this is something to keep in mind for next year? Sylvester ------------------------------------------------------------------------------ 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
