# thoughts on "style editor" team role and repo maintenance

**URL:** <https://discourse.citationstyles.org/t/thoughts-on-style-editor-team-role-and-repo-maintenance/938>\
**Category:** CSL Development\
**Created:** [January 9, 2011, 3:53pm UTC](https://discourse.citationstyles.org/t/thoughts-on-style-editor-team-role-and-repo-maintenance/938 "2011-01-09T15:53:13Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [January 9, 2011, 3:53pm UTC](https://discourse.citationstyles.org/t/thoughts-on-style-editor-team-role-and-repo-maintenance/938/1 "2011-01-09T15:53:13Z")

</div>

So basic idea behind the style editor team role is these are users who  
have authority to write (say by pulling from other repos) changes to  
the main csl repo. Ideally, I’d like 10 or so good people, from a  
variety of projects.

I think to do that well, we need two things:

1. obviously some technical competence on the part of the team members

2. a common standard to assess patches from potentially disparate  
sources (Mendeley, Zotero, pandoc/citeproc, etc.). I think to do this,  
in general (including for a nice GUI web app), we need standard input  
data, and some way to easily diff the output results in preview.  
Perhaps this could be achieved using a simple little JS app that uses  
some standard JSON input data and builds on Frank’s code?

Bruce

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [January 16, 2011, 5:14pm UTC](https://discourse.citationstyles.org/t/thoughts-on-style-editor-team-role-and-repo-maintenance/938/2 "2011-01-16T17:14:52Z")

</div>

Two things related to this, which essentially boil down to "how to  
replace and extend feature at [zotero.org/styles."](http://zotero.org/styles.%22)

First, Rintze and I were working on a little detail off-list, which is  
figuring out how to deal with the csl:updated value in styles in the  
context of a DVCS.

In SVN/CSL, you might do this sort of thing with keyword expansion,  
but this doesn’t really make sense in a DVCS for a variety of reasons.  
At the same time, it doesn’t really make sense to make people manually  
update these values: for the person doing it, it’s a hassle certainly,  
but it’s also conceptually problematic because you’re tracking content  
that really should be maintained by the VCS.

So, Rintze came across some information about workarounds in git:

> <https://stackoverflow.com/questions/2316677/can-git-automatically-switch-between-spaces-and-tabs>

[http://progit.org/book/ch7-2.html](http://progit.org/book/ch7-2.html)

> <https://stackoverflow.com/questions/2315771/writing-a-git-hook-to-automatically-modify-code-during-local-commits>

… and I figured out something basic, which is how to get git to  
return the last modified date for a file, in iso date-time format:

$ git log --date=iso --pretty=format:"%ad" -1 style.csl  
2010-12-18 20:06:10 -0500

The second point is the related preview and diff issue.

With the VCS, we can know the change history of a style: when changes  
were applied, and what they were. So we can use that to visually  
compare output results of patches. I think I conclude the best way to  
do this is to able to use something like the preview code in the csl  
editor in conjunction with some sort of HTML diff library that shows  
how CSL changes are impacting output results.

Bruce

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [January 16, 2011, 9:46pm UTC](https://discourse.citationstyles.org/t/thoughts-on-style-editor-team-role-and-repo-maintenance/938/3 "2011-01-16T21:46:42Z")

</div>

Another random thought:

GitHub actually has a pretty nice UI for forking and pulling code  
changes. What it doesn’t have is any dedicated way to visualize  
changes with CSL styles.

I wonder if, as the simplest possible approach that could work now,  
with no infrastructure, it’d be feasible to write a little  
bookmarklet\* that allowed one to click on it when on a pull request  
page, and have it drop down the rendered preview diff?

So the workflow for style editor teams would be:

1. click on pull request to view changes and comments\*\*
2. click “preview changes” bookmarklet to check if they make sense; if  
no, add comment; if yes
3. pull changes

Bruce

- using something like [http://github.com/judofyr/github-js](http://github.com/judofyr/github-js)  
\*\* e.g. [http://github.com/mojombo/jekyll/pull/265](http://github.com/mojombo/jekyll/pull/265)

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [January 16, 2011, 10:06pm UTC](https://discourse.citationstyles.org/t/thoughts-on-style-editor-team-role-and-repo-maintenance/938/4 "2011-01-16T22:06:36Z")

</div>

OTOH, it’s simple enough, and the API rich enough\*, that it shouldn’t  
be hard to recreate.

Bruce

- [http://develop.github.com/p/pulls.html](http://develop.github.com/p/pulls.html)

---

<div class="post-metadata">

**Author:** ![Carles\_Pina](https://avatars.discourse-cdn.com/v4/letter/c/dbc845/32.png) [@Carles\_Pina](https://discourse.citationstyles.org/u/Carles_Pina)\
**Post date:** [January 18, 2011, 10:12am UTC](https://discourse.citationstyles.org/t/thoughts-on-style-editor-team-role-and-repo-maintenance/938/5 "2011-01-18T10:12:47Z")

</div>

Hello,

> > So basic idea behind the style editor team role is these are users who  
> > have authority to write (say by pulling from other repos) changes to  
> > the main csl repo. Ideally, I’d like 10 or so good people, from a  
> > variety of projects.
> > 
> > I think to do that well, we need two things:
> > 
> > 1. obviously some technical competence on the part of the team members
> > 
> > 2. a common standard to assess patches from potentially disparate  
> > sources (Mendeley, Zotero, pandoc/citeproc, etc.). I think to do this,  
> > in general (including for a nice GUI web app), we need standard input  
> > data, and some way to easily diff the output results in preview.  
> > Perhaps this could be achieved using a simple little JS app that uses  
> > some standard JSON input data and builds on Frank’s code?
> 
> Two things related to this, which essentially boil down to “how to  
> replace and extend feature at [zotero.org/styles.](http://zotero.org/styles.)”
> 
> First, Rintze and I were working on a little detail off-list, which is  
> figuring out how to deal with the csl:updated value in styles in the  
> context of a DVCS.
> 
> In SVN/CSL, you might do this sort of thing with keyword expansion,  
> but this doesn’t really make sense in a DVCS for a variety of reasons.  
> At the same time, it doesn’t really make sense to make people manually  
> update these values: for the person doing it, it’s a hassle certainly,  
> but it’s also conceptually problematic because you’re tracking content  
> that really should be maintained by the VCS.
> 
> So, Rintze came across some information about workarounds in git:
> 
> [Can git automatically switch between spaces and tabs? - Stack Overflow](http://stackoverflow.com/questions/2316677/can-git-automatically-switch-between-spaces-and-tabs)
> 
> [http://progit.org/book/ch7-2.html](http://progit.org/book/ch7-2.html)
> 
> [Writing a git hook to automatically modify code during local commits - Stack Overflow](http://stackoverflow.com/questions/2315771/writing-a-git-hook-to-automatically-modify-code-during-local-commits)
> 
> … and I figured out something basic, which is how to get git to  
> return the last modified date for a file, in iso date-time format:
> 
> $ git log --date=iso --pretty=format:“%ad” -1 style.csl  
> 2010-12-18 20:06:10 -0500
> 
> The second point is the related preview and diff issue.

that nice for the updated, I liked.  
Do we want to run the hooks in server side, right? Github does support it?  
(if it’s client side we will need some way to enforce the clients to  
setup the hooks)

Have you thought about the id and how to handle it in different  
branches of the same style?  
I think that we talked about it but we didn’t have a final solution.

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [January 18, 2011, 1:53pm UTC](https://discourse.citationstyles.org/t/thoughts-on-style-editor-team-role-and-repo-maintenance/938/6 "2011-01-18T13:53:51Z")

</div>

I hadn’t gotten to the details, given that I’ve yet to see anyone (say  
from Mendeley, or Zotero) sign up for the org team, or commit a change  
😉

I guess I’d probably lean towards adopting an approach consistent with  
git/github. So I would expect, for example, that a style that in that  
system is …

citation-style-language/styles/apa.csl

… might, if forked, become:

jdoe/styles/apa.csl

But OTOH, this is also similar to the updated issue in that it might  
be odd to be messing with the id. I guess we’re going to have to think  
about this more and consider exactly what we need to achieve (most  
importantly is probably just knowing when two files are the same  
style).

Bruce

---

<div class="post-metadata">

**Author:** ![Carles\_Pina](https://avatars.discourse-cdn.com/v4/letter/c/dbc845/32.png) [@Carles\_Pina](https://discourse.citationstyles.org/u/Carles_Pina)\
**Post date:** [January 18, 2011, 2:05pm UTC](https://discourse.citationstyles.org/t/thoughts-on-style-editor-team-role-and-repo-maintenance/938/7 "2011-01-18T14:05:45Z")

</div>

Hi,

> > Have you thought about the id and how to handle it in different  
> > branches of the same style?  
> > I think that we talked about it but we didn’t have a final solution.
> 
> I hadn’t gotten to the details, given that I’ve yet to see anyone (say  
> from Mendeley, or Zotero) sign up for the org team, or commit a change  
> 😉

I’ll fix it soon 🙂

> I guess I’d probably lean towards adopting an approach consistent with  
> git/github. So I would expect, for example, that a style that in that  
> system is …
> 
> citation-style-language/styles/apa.csl
> 
> … might, if forked, become:
> 
> jdoe/styles/apa.csl
> 
> But OTOH, this is also similar to the updated issue in that it might  
> be odd to be messing with the id. I guess we’re going to have to think  
> about this more and consider exactly what we need to achieve (most  
> importantly is probably just knowing when two files are the same  
> style).

Also important: what is the same style.

And how to handle pull requests/merges from forked styles.

As I think that I said before here, let’s say that I fork apa.csl  
because I want to change something. Then my colleagues starts using  
cpina/styles/apa.csl. So far, so good.

Then, the committee decides to pull my changes because it’s “approved”.

In that point, me and my colleagues will be still using  
cpina/styles/apa.csl but should use apa.csl.

I’m not sure how to handle this case. Any ideas?

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [January 18, 2011, 2:21pm UTC](https://discourse.citationstyles.org/t/thoughts-on-style-editor-team-role-and-repo-maintenance/938/8 "2011-01-18T14:21:25Z")

</div>

> Hi,
> 
> > > Have you thought about the id and how to handle it in different  
> > > branches of the same style?  
> > > I think that we talked about it but we didn’t have a final solution.
> > 
> > I hadn’t gotten to the details, given that I’ve yet to see anyone (say  
> > from Mendeley, or Zotero) sign up for the org team, or commit a change  
> > 😉
> 
> I’ll fix it soon 🙂
> 
> > I guess I’d probably lean towards adopting an approach consistent with  
> > git/github. So I would expect, for example, that a style that in that  
> > system is …
> > 
> > citation-style-language/styles/apa.csl
> > 
> > … might, if forked, become:
> > 
> > jdoe/styles/apa.csl
> > 
> > But OTOH, this is also similar to the updated issue in that it might  
> > be odd to be messing with the id. I guess we’re going to have to think  
> > about this more and consider exactly what we need to achieve (most  
> > importantly is probably just knowing when two files are the same  
> > style).
> 
> Also important: what is the same style.
> 
> And how to handle pull requests/merges from forked styles.
> 
> As I think that I said before here, let’s say that I fork apa.csl  
> because I want to change something. Then my colleagues starts using  
> cpina/styles/apa.csl. So far, so good.
> 
> Then, the committee decides to pull my changes because it’s “approved”.
> 
> In that point, me and my colleagues will be still using  
> cpina/styles/apa.csl but should use apa.csl.
> 
> I’m not sure how to handle this case. Any ideas?

So ideally, we really need the client software to have some concept of  
a fork and merge.

> From the git perspective, the github api exposes network information.  
> An example of a fork (the schacon/grit repo of the mojombo/grit  
> source) from their docs (I assume git itself stores similar info, but  
> am not sure):

$ curl [http://github.com/api/v2/json/repos/show/schacon/grit](http://github.com/api/v2/json/repos/show/schacon/grit)  
{  
“repository”: {  
“url”: “[GitHub - schacon/grit: Grit is a Ruby library for extracting information from a git repository in an object oriented manner - this fork tries to intergrate as much pure-ruby functionality as possible](https://github.com/schacon/grit)”,  
“has\_issues”: true,  
“homepage”: “[http://grit.rubyforge.org/](http://grit.rubyforge.org/)”,  
“watchers”: 106,  
“source”: “mojombo/grit”,  
“parent”: “mojombo/grit”,  
“has\_downloads”: true,  
“created\_at”: “2008/04/18 16:14:24 -0700”,  
“forks”: 11,  
“fork”: true,  
“has\_wiki”: true,  
“private”: false,  
“pushed\_at”: “2010/05/05 15:28:38 -0700”,  
“name”: “grit”,  
“description”: “Grit is a Ruby library for extracting information  
from a git repository in an object oriented manner - this fork tries  
to intergrate as much pure-ruby functionality as possible”,  
“owner”: “schacon”,  
“open\_issues”: 0  
}  
}

Bruce

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [January 18, 2011, 2:39pm UTC](https://discourse.citationstyles.org/t/thoughts-on-style-editor-team-role-and-repo-maintenance/938/9 "2011-01-18T14:39:39Z")

</div>

I just tested this with a fork repo I have, and from what I can tell  
(looking through the contents of the .git directory), it does not  
store information about the source of the fork.

Bruce