For the past few years, I’ve been saying the interface really needs to
be wizard-based, and that early in that process, the user should be
prompted to base a new style on an existing style. Those that require
I agree. Some time ago we had here some brainstorming on that.
subsequent minor edits become standalone styles. Those that don’t
become dependent styles.
To give some more context: I’m focusing now how to integrate the Style
Editor in $your_product, and how it’s connected with the main CSL
repository. My particular case is Mendeley, but I think that the
discussion is product agnostic.
Ideas for this workflow?
I’m also trying to think some other application in some field that
works like this but I don’t have any example.
In general, my preference is to start with the simple and the social,
but leave room for the more complex case to develop as needed. So,
e.g., maybe we start with a basic repository running that allows
anyone to submit comments on a style page, and then we have 5-10 power
users of sorts (ones who know how to edit the raw CSL files) who can
create those changes. This would allow us to test this forking/merging
I do understand what you say. But I’m thinking “around” the style
editor and how it fits in the ecosystem, not how to edit raw CSL
files. In particular, the typical cases like “I want X style but
instead of square brackets I want parenthesis” and similar small
changes and that the user is up to do it himself and now (and not to
go to a webpage to leave a comment).
I can see different use cases:
a) user wants to create a dependant style
b) user wants to fix some bug in some style
c) user wants to create a new style based in some existing style
d) user wants to create a new style from the scratch
Case by case:
a) user wants to create a dependant style: if the user edits a style
and only changes the metadata, the output of the style editor should
be a dependant style.
b) user wants to fix some bug in some style: the user would edit it
(with the style editor), mark as a bugfix, and write some commit
message. Somebody should review this change and if it’s accepted merge
to the main style. But, meanwhile, the user wants to use "his"
version. And maybe the user wants to share “his” version with
colleagues and collaborators, the plugins will fetch it automatically,
c) is similar to b, but instead of “merging” later on it will be
needed to be added.
d) similar to c), but the style editor would start blank instead of
with some things there.
For starting, and looking in the case b): which styleId should have
the temporary style? and which name? I say temporary style, but maybe
it’s never merged but still useful for this user for some reason. And
when it’s merged: citationstyles.org should keep serving the old
version or because has been merged should serve the last version of
the main style?
Even here I can see some oddities. Say you have a styles repo that is
a fork of mine. You make a minor changes in apa.csl and issue a pull
request, which I accept. If we change the id for each edit or editor,
then a big part of the change history for the repository will just be
I think that everyone agrees that the style ID has to be as stable as
possible. Other thing is that I create my APA (apa-Carles) until it’s
pulled by the main style. The StyleId of the main style should not
change when pulls modifications.