Good idea. We could use a label or a column on the board.
I’m personally not convinced we need separate files any more. My original post was from a time before issue template or project boards, so issues were quite limited as organizational tools. I’ve only skimmed the above discussion so far and will look at the project board later, but as a general approach this works for me.
(Thanks for doing all the recent work on this; like Rintze, I’m doing childcare & work currently, so time is extra scarce, but will try to chime in where most helpful. I’ll try to keep an eye on gh mentions if you particularly want my input somewhere)
Oh, that’s a good time problem to have @Sebastian_Karcher!
Yes, to quickly grok where we’re at now, look at the project board, and the intext issue I added to it (where I was testing out a potential template model for these issues).
Hi all, my open source time is extremely limited nowadays, so I’ll probably won’t be able to keep up with discussions (I might also step away as co-maintainer of the CSL styles repository at some point after doing that for a decade). Happy to help set somebody trusted up as a project maintainer. Please use my personal email if I don’t respond to a mention.
1 Like
@Denis_Maier - why the “next” project column? It’s ambiguous, but suggests to me a version. So why do we need that?
I was getting confused about whether some items should be there, or “accepted.”
I was just thinking putting everything next in accepted, which is not set in stone. We can basically make a suggestion, ask people to review, and then go from there.
Was just an idea to focus on a few items at a time (see my comments here). If it’s not useful we can just remove the column.
Per the other thread, I renamed to “In Progress.”
@Denis_Maier and I have triaged at least many of the main issues.
I was fairly liberal about including issues in accepted when they involved item types or similar simple changes.
Picking up a point raised by @Sebastian_Karcher, I suggest we remove zotero-bits as a linked repo on the CSL projects, and instead create parallel issues in the CSL repos, which then get added to the project.
Does that make sense?
Can’t we just move the CSL issues to evolution, as per @bwiernik’s suggestion?
How about if it’s clearly focused on CSL, then move to evolution.
Otherwise (if includes aspects that are about zotero), create new and link?
BTW, this example is probably the former, but I did it as a test.
Only question is, who is responsible for zotero-bits? Do we risk pissing anyone off if we move an issue?
There’s no one strictly in charge of the repo, but @Dan_Stillman did request that Rintze transfer it to Zotero, since they’re also working on field updates there and Rintze suggested to keep it here (and allow Zotero to work with the tickets) because of the CSL component, so I think it’d be good to not move anything that also has Zotero content (e.g., new item types in Zotero and CSL) out of the repository; sorry if that creates additional complications in workflow
In that case, we should not transfer at all, I’d say.
I don’t think it’s a big hassle; in some ways, actually easier.
Ok, then we need to create new issues for the ones coming from zotero-bits. I can take a couple of them, but maybe not until tomorrow.
No problem.
I’ll do a few too. There aren’t many.
Done for all but one, I think.
It’s easy: add new issue to evolution with link to zotero-bit issue, and add to project before saving; then go to linked issue and remove from project there.
Each one took maybe 30 seconds.
I also loosely ordered the accepted one; so grouping together new variables, for example.
I also changed some titles for consistency, and also to make easier to filter, and aligned label names and colors so they are consistent. Again, makes is easier to read and to filter (you can click on a label to filter on it, and it works across the repos).
Great, thank you.
(Just for the record, I can only add an issue to the board from the board interface not from the issue itself. Probably due to repo rights settings.)