As indicated in my very first email, I had 2 other emails I wanted to send to this list as well. Here is the first one…
I hope I’ve made it clear in my introduction email that we are very happy with CSl and commited to make it work as well as we can, with our limited resources.
One area where we thought we could contribute back with our limited resources was to encourage our most adventurous users to create their own styles. We have put instructions for them here:
But we thought we could go one step further, and give more incentive to do so. We have this idea of giving away free Papers2 serials for contributions to the CSL repository. It’s not fully flushed out, but I thought I could consult with you guys first and make sure it’s a good idea, and that we are not doing something stupid in the process. Here is a link to the current draft of what we’ll be making public if we go ahead with the idea:
One area where we thought we could contribute back with our limited
resources was to encourage our most adventurous users to create their own
styles. …
But we thought we could go one step further, and give more incentive to do
so. We have this idea of giving away free Papers2 serials for contributions
to the CSL repository. It’s not fully flushed out, but I thought I could
consult with you guys first and make sure it’s a good idea, and that we are
not doing something stupid in the process. Here is a link to the current
draft of what we’ll be making public if we go ahead with the idea:
It’s a minor niggle, but please always first use the full “Citation Style
Language” name before abbreviating to “CSL”.
Another requirement I would add is to clearly mention that only styles
that are valid CSL 1.0 will be considered for inclusion in the style
repository (which also means no Papers2-specific CSL variables).
I’m not sure you should require an email address. I personally have
always been hesitant to include mine out of fear for spam.
I think it’s a great idea, but I’m curious about Sebastian’s opinion, since
he has been (very kindly) handling most of the user-contributed styles for
quite a while now.
RintzeOn Tue, Dec 20, 2011 at 3:00 AM, Charles Parnot <@Charles_Parnot>wrote:
good to hear from you Charles,
First, let me say that I’m very happy that you’re encouraging and
getting your users to contribute styles.
As for serials, yes, I agree this is a great idea - I just mentioned
to Sean (of Zotero) that I’m a little wary of monetary bounties, but
serials as bounty sound like a great solution to me.
I’m happy for Charles to have commit access - that seems like the most
convenient solution for everyone (though I’d be happy to handle pull
requests, too). The obvious expectation would be that you validate any
style before committing it - as Rintze explains the repository is for
valid csl 1.0 styles only (we’re e.g. also not committing styles with
csl 1.0.1 features even when they’re already functional in citeproc-js
and thus Zotero).
As for the papers specific variables you added - I believe PMID and
PMCID are planned so those could just be mapped back to generic csl
variables once they’re introduced. Is there any reason you’re not
mapping papers_note to “note”?
Best,
Sebastian
… The obvious expectation would be that you validate any
style before committing it - as Rintze explains the repository is for
valid csl 1.0 styles only (we’re e.g. also not committing styles with
csl 1.0.1 features even when they’re already functional in citeproc-js
and thus Zotero).
I’m leery about this (until now, I believe, unstated) policy. The very
logic of our schema versioning plans suggests any 1.0x style should be
included in the repo the same as any other.
So why are we doing this?
Of course, we still haven’t figured out how we’re going to deal with
the more major version changes.
This raises a point about our way of handling releases though. If we could
be confident that CSL processors wouldn’t break by new elements and/or
attributes, we could move to a more fluid release schedule where features
can be added to styles in the repo once consensus has been reached to
include those features into the next CSL release.
This raises a point about our way of handling releases though. If we could
be confident that CSL processors wouldn’t break by new elements and/or
attributes, we could move to a more fluid release schedule where features
can be added to styles in the repo once consensus has been reached to
include those features into the next CSL release.
that would be very useful - the status quo is a little unsatisfactory,
because we also don’t have a good way of tracking styles where
features (I’m mainly thinking of delimiter-precedes-et-al right now)
need to be added in the future - I know there are a bunch of styles
with that requirement but I wouldn’t know how to track them down
easily right now - much easier if it could have been just
implemented…–
Sebastian Karcher
Ph.D. Candidate
Department of Political Science
Northwestern University
This raises a point about our way of handling releases though. If we
could
be confident that CSL processors wouldn’t break by new elements and/or
attributes, we could move to a more fluid release schedule where features
can be added to styles in the repo once consensus has been reached to
include those features into the next CSL release.
that would be very useful - the status quo is a little unsatisfactory,
because we also don’t have a good way of tracking styles where
features (I’m mainly thinking of delimiter-precedes-et-al right now)
need to be added in the future - I know there are a bunch of styles
with that requirement but I wouldn’t know how to track them down
easily right now - much easier if it could have been just
implemented…
We would need confirmation from at least Frank (citeproc-js), Charles
(Papers2 CSL processor), Sylvester (citeproc-rb) and Andrea (citeproc-hs)
that such a change in our release workflow won’t give problems, though.
(are there any other CSL processors used in production settings that I
missed?)
One question: how would you ensure quality (and uniqueness)?
By manually verifying the entry (hence the requirement to include a link to e.g. the instructions to authors). But then, that was also in fact why I posted this to you guys first. How do you judge that?
In any case, we don’t expect a huge number of styles, even a few dozens would be a great success. We’ll see: if we are overwhelmed, that will be a good problem to have for us (Mekentosj) and for everybody, isn’t it?
It’s a minor niggle, but please always first use the full “Citation Style Language” name before abbreviating to “CSL”.
Ah, good point, totally agreed! I’ll make that change before we post the thing.
Another requirement I would add is to clearly mention that only styles that are valid CSL 1.0 will be considered for inclusion in the style repository (which also means no Papers2-specific CSL variables).
Yes, though it’s part of the CSL rules for submitting new styles, and I point to the CSL wiki for that. But to be clear, I have added that specific requirements to the text we would post.
I’m not sure you should require an email address. I personally have always been hesitant to include mine out of fear for spam.
I’ll leave it as is, because I do think anybody who posts something for others to use needs to take responsibility, so we’ll call that the Mekentosj’ requirement
I think that can be part of that quality issue you also raised. Of course, if somebody is reluctant to add their email, I’ll bend the rules…
I’m happy for Charles to have commit access - that seems like the most…
I’d be happy with that, then. I only have 5 styles added to Papers2, and contributed by users (and me). So that will be a first interesting trial. I’ll do that when I am back to work, though, after the 24th.
Same for the fixtures. Some might be useful for you guys too, I’ll be sure to only add relevant ones.
Let me know if/when I get commit access, then.
As for the papers specific variables you added - I believe PMID and PMCID are planned so those could just be mapped back to generic csl variables once they’re introduced.
That would be awesome, great! Bruce mentioned I should add that to the feature requests, I’ll have to look into that.
Is there any reason you’re not mapping papers_note to “note”?
I was worried about this, because we already have the problem with BibTeX users, that actually use ‘note’ for inclusion in the bibliography. Typically, Papers2 notes are longer, more like quick personal notes and thoughts on a paper, and not relevant at all for a bibliography. In this case, this is thus more a convenient way for users to spit out all their notes in combination with a reference. I only added this one because of one user request.
We would need confirmation from at least Frank (citeproc-js), Charles (Papers2 CSL processor), Sylvester (citeproc-rb) and Andrea (citeproc-hs) that such a change in our release workflow won’t give problems, though. (are there any other CSL processors used in production settings that I missed?)
Unknown variables and unknown attributes are handled “gracefully” on my end, as they are simply ignored.
Thinking about CSL versioning and how to handle transitions: aren’t implementations supposed to check the version number and then could decide not to use a style if in a version more recent than they support? For instance, I could imagine that I would change my implementation now to ignore any styles higher than 1.0 (right now, it’s blissfully ignoring the version!), so that it won’t even allow newer styles to be used, maybe with some error message to the user. Alternatively, if we know now that subpoint release are backwards-compatible, except for new variables and attributes, I could decide to support up to 1.0.x, but then leave out anything at 1.1 or higher. Maybe to know what’s the best approach, we need to go through one such transition with some basic rules in mind, see how it goes, then learn from that for the next transition.
I’m happy for Charles to have commit access - that seems like the
most…
I’d be happy with that, then. I only have 5 styles added to Papers2, and
contributed by users (and me). So that will be a first interesting trial.
I’ll do that when I am back to work, though, after the 24th.
Same for the fixtures. Some might be useful for you guys too, I’ll be sure
to only add relevant ones.
Let me know if/when I get commit access, then.
You should already have commit access to the style repo.
As for the papers specific variables you added - I believe PMID and PMCID
are planned so those could just be mapped back to generic csl variables
once they’re introduced.
That would be awesome, great! Bruce mentioned I should add that to the
feature requests, I’ll have to look into that.
The CSL ticket for PMID/PMCID variables (which I’ve already closed since I
didn’t expect/want objections):
RintzeOn Wed, Dec 21, 2011 at 2:32 AM, Charles Parnot <@Charles_Parnot>wrote:
