Where do you get that search view? I can only use the main search interface, but browsing through the results is not really intuitive. If you don’t have to migrate the issues—great! But there should be some way to have sort of a global view.
By clicking the “add cards” link on the upper right.
Not available for me.
Probably you just don’t have the correct rights?
You mean “don’t have”, right? That’s possible.
1 Like
One big question we would need to settle is whether to have one big “roadmap” project (doom), or multiple ones; per release (test CSL org project).
There are general pros and cons to each. Which suits this work the best?
Having multiple projects is probably the better approach. (One for general discussion about the need of feature x, another one concerned with implementation details and focussed on individual releases.)
So a general project in that model would have columns like proposed, rejected, accepted, and the release ones would have accepted, in progress, and done?
Something like that?
What about: Proposed, rejected, accepted, assigned
Yeah. Or: to do, in progress, done
Ok, I’m going to summarize where @Denis_Maier and I have taken this conversation, for broader comment when people are able (I hope everyone is OK).
I propose we:
- focus our efforts on the GitHub Projects feature to manage workflow
- add a “General” (or similar) project to the CSL org projects, with “proposed”, “accepted” (or “approved”), and “rejected” columns; use version labels to associate approved/accepted items with release projects
- add a “v2.0” project, with “to do”, “in progress” and “done”
- revise the v1.1 project to conform to 3
Not settled:
- I still think it’s easier to discuss proposals when they come in the form of a PR on the schema and documentation. If they are in separate repos, how does this work? Maybe just link them?
- How we setup the more complex functionality so easiest to manage? We might need help on this.
1 Like
In addition to that:
Somewhere along the way, it was suggested that we adopt a more structured feature proposal template. Each proposal should be uploaded as a single markdown file like they use for Swift development. I like the structured approach, but I think this is probably to much. I suggest we use Github issue templates for this:
1 Like
You can take a look at this PR to see how project integration works on that end.
You can also change project status manually on the ticket like so.
I don’t think our main problem currently is going from acceptance to deployment, but rather everything that comes before acceptane, like having a structured discussion, coming to a decision, and making sure that items don’t get lost somewhere along the way. At this point there usually won’t be any PRs to discuss.
I think this is what @Rintze_Zelle tried to address with these suggestion in this issue:
- Core team creates and/or triages incoming issues on CSL development. I think we should centralize everything into this issue tracker, linking to issues in other repos as appropriate, so that it’s enough for non-core folks to keep an eye on this repo.
- Core team make sure issues contain minimum amount of information to support the request for change. I.e., it’s really helpful if we determine early on whether there e.g. are style guides that describe certain requirements we currently don’t yet support.
- Once the need has been established, we can start coming up with one or more solutions.
(OTOH, one may question if github is the right place to have these kind of discussions. Some people seem to prefer a forum like this for such matters.)
Also, I have the impression that he wanted to discuss conceptual and implementation related issues in different places. I don’t know if that’s realistic though. Afterall, CSL is not a huge organization like Swift where such a structure clearly makes sense.
1 Like
You raise a good point, which is really that there are different stages of FRs, that happens in different places. Most of us don’t have the time to follow everything, so why this is important.
I think the gist of what we’re trying to sort out is how to streamline process within and (mostly) across those stages.
Stages might be something like:
- initial requirements and problem scoping (what is the request, and why is it needed in CSL?)
- review basic request and approve/reject; if approved then …
- in-progress development of specific implementation details
- review 3 and approve/reject
Sometimes, 2 and 3 can be combined.
In my experience, LOONG and winding conversations can happen at any of these stages, mostly because people mix different stages together.
For example, someone will say on the zotero forums (which I haven’t really followed in years for lack of time) “I need feature X, here’s how it should work” and then chaos of sorts ensues.
Anyway, what I’m thinking of the what and where of the substance of those stages.
- this can happen anywhere, and can and should involve end users; obvious places are the zotero forums, and here
- here’s where we begin to consolidate on github, and where the template you posted makes sense; so we have a common and concise way to evaluate
- git commits; actual, specific, changes to schema and spec; for example, @Frank_Bennett opened up a new branch on citeproc-js and started figuring out how to do intext citations. So this can be distributed of course.
- pull requests of the outcome of 3 on the main CSL repos, linked to the issues created and approved in step 2
I think this is consistent with what you quoted from Rintze, but more specific and structured.
Nice summary, thanks.
So, to put that into practice with a concrete example: let’s play the first steps through with @bwiernik’s proposal to add new elements to names:
- On March, 20, @bwiernik proposed to extend the data model for name elements, i.e., to add
alternate-name, androleorlabelelements. There has been a bit of discussion. The proposal seems to be reasonable, but the details are still not fully worked out. But at least, there were no objections to the general usefullness of the idea.
=> So, I guess we should now move to stage 2. (The problem is, of course, that I was the only respondend in that thread; can we assume from the fact that nobody else answered that there are no principal objections?)
- That would be to open an issue on github (ideally on the evolution repo), to propose the feature in a more structured way, and to work out the exact details. The obvious question is: When can we say that step is finished?
Let’s say, someone opens an issue today or tomorrow, and we’d need another week to discuss the remaining open questions. That means we’d have a proposal by the end of next week.
But then? We will want to have an additional period for comments, perhaps two weeks? At that point we should probably be able to decide if this feature should be implemented.
If yes, we’d have to decide if this is for the next release or for later.
What do you think? Is that feasible?
Maybe there’s a standard review and comment period as you suggest (two weeks seems good, though of course the current crisis compromises this notion of time severely), but then the actual signal that this step is done is when some number of reviewers approve or reject.
As in, this is where we’d use the project automation functionality, and where a rejected proposal would move to the “rejected” column, etc.
We could then use labels to suggest release targets, solicit PRs, etc., all of which we could automate (hopefully) to populate the project columns correctly, so people (including us) could easily see what stage a proposal was at, what needs to be done, etc.?
Yes, but here’s the next question: should we move with step 3 to another repo (schema and documentation)?
Advantage: You don’t have to follow everything. (If you’re only interested in the conceptual issues you only need to watch the evolution repo, and so on.)
We can either create a new issue in the schema repo (with a link to the issue in the evolution repo), or we transfer the issue. That way, issues would start in the evolution repo, but would then end up in the schema repo, where we would assign them to a certain release. (I suggest we adopt that as a workflow.)
1 Like
@Sebastian_Karcher sketched some of this out as well a few years ago here.
I don’t think I agree with his #1 point; that instead every issue should be an issue, using the template.
Maybe, but I’m not sure (as in, I really don’t know ATM) if the github issue and project integration starts to break down when you do that.
In other words, I don’t think you can “move” an issue from one repo tracker to another; you have to instead create two and link them.
I don’t think I agree with his #1 point; that instead every issue should be an issue, using the template.
Yeah, I remember this post, but couldn’t find it again. Thanks for adding the link.
@Sebastian_Karcher’s suggestions is basically to adopt the Swift approach. I’d also prefer to use issues instead of markdown files.