As we’ve now, I think, figured out the question of how to add intext or narrative citation styling to CSL, the obvious question is the process by which we get from here (the solution) to there (deployment).
This has been a long-running question, as @Rintze_Zelle laid out here.
I suggest there that we make use of github’s project feature, and consolidate that on the schema repo.
Here’s a screenshot to setup automation, with a review requirement (though I haven’t yet figured out how to configure who are reviewers, and how many reviewers are required for approval).
So, we need to consolidate all CSL related issues in one place. Any objections? Currently, it seems to be scattered all over the place, things being discussed at multiple places. Obviously, that’s not quite ideal. Schema would be a good place.
It also occurs to me we really need the spec in the same place as the schema, so that the process for feature proposals is really a PR, with patches for schema and spec.
Could we just move the documentation repo to the schema repo, either as a submodule (though not sure if this helps in terms of management going forward), or directly as a subdirectory?
I think ideally, we need to require reviews from some number of the core CSL team, and maybe some number of non-core implementers.
If I read the docs correctly, we could setup “teams” for those two groups, and then configure the review process.
Maybe even add a third group for @Frank_Bennett - who is both a core team member, and a key implementer. But this would assume he would be required alone to approve everything, which may not be super practical for him.
Obviously, we’d need some clear ground rules to setup this up correctly, but it seems like it could dramatically simplify our work.
Concering the stacks: The doom example you’ve linked is good. Or, we use a more fine grained approach:
One Project for the assessment of features: Proposed, Rejected, Approved, Assigned (to a release)
Then, one project for each release: To Do, In Progress, Done
(But perhaps this is overkill…)
Why not start with one board “Roadmap”, and—once we start having a new release every other month—add new projects for individual releases?
I’ve had a look at the project board. I’m not sure what the “done” stack is supposed to mean. Does that mean implemented? Or accepted?
Doom’s solution looks better to me. After review we’d need a stack for rejected proposals, another for accepted proposals, but yet unassigned proposals. Accepted proposals should then be assigned to a release.
What do you think?
But, the question how a proposal is to be accepted has still to be answered.
Another question: Who is going to add issues to that board. Everyone? Team members? Do we want to have the discussion about features there? Or should discussion about the usefullness of features take place here, github issues being reserved for actual implementation details…
I just used the default, and added two version columns. Definitely intending to change that.
These are the key questions, and I’m not sure. I hope others will respond to them.
But some possibilities to consider:
I think we need people (which is not me) following tickets in last couple years relatively closely to know what issues should be put on which columns (what you call stacks).
I would suggest they do that, so triaging things we’re approving (or considering approving), things we’re rejecting, etc.
Maybe when that’s done, they could post a thread here updating on that, and encouraging people to review and make any recommendations?
I updated some of the column names away from the defaults.
I think the idea of this workflow is once something specific is approved and implemented (in my idea, schema and documentation patches merged to develop), it first moves to “done” column automatically, and then when assigned to a release, goes to the version column.
So the intext thing, once accepted, would ultimately end up on the v2.0 column.
Here’s an excellent article on some of the finepoints of setting up projects (including hooks into the label system). So among other things, we’d want to revisit the existing labels, and then set them up to tightly integrate with the project.
Perhaps it’s easier to address the easier problem first. Why don’t we start centralizing all issues in one place? I wouldn’t mind if’s in evolution or in schema. The need to centralize the issues should be fairly uncontroversial. (I don’t know how easy that is. Can we just move the issues or do we need to create new issues?)
