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
