Well, it should work. I have set up two demo repos, and two global projects.
I had one issue in the one repo and in one project. When the issue reached the done column on the project board, I transfered the issue to the other repo, removed it from one project board and added it to the other. Looks like you can even have one issue on two boards. Try yourself, I’ve added you as a collaborator to the board.
(We should really make sure that this works reliably, of course.)
Oh, I totally missed that “transfer issue” thing!
I created an issue, using the narrative citation case. I added a link to the org project, and then it added it to the correct column. I was also testing out a potential template structure.
Comments?
One downside is I couldn’t figure out how to quickly link to the issues/PR on the other repos.
Great, the proposal looks good.
However, I think the proposal is on the wrong board, I suggest you create an organization-wide project board called “Proposal Discussion”, and then add this proposal to that board. I assume that the “CSL 2.0 Development” project should be only used for already approved proposals.
In turn, we can use this organization-wide “Proposal Discussion” board to gather all open proposals/issues from evolution, schema and zotero-bits, and—if we decide to implement them—move them either to a “v1.1.” board or to the “CSL 2.0 Development” board.
What do you think?
(The problem with using that issue as a test case is that we already have a pull request and that it’s already in the implementation stage. It might be reasonable to assume that this is already accepted; then I suggest you copy the proposal text to the PR.)
Maybe @bwiernik could create one for his issue?
Yes, that would be a good example and test case. But that should as well end up on a “Proposal Discussion” board.
I don’t have time to do more ATM, but:
I can’t see that board.
Ok, now it’s there. Perhaps you should link the “Zotero-bits” repo as well so we can add issues from there to the board. Otherwise the issues have to be transfered to the evolution repo.
I think Sebastian’s original idea for making proposals files with associated pull requests/issues is a good one. That will make discussing changes to wording, etc. easier and, once a proposal is accepted, the text is all ready to go for copying to the relevant place in the schema/spec.
I can make a submission for the names proposal. It would also be good to consolidate the zotero-bits issues into formal proposals. I think starting with the issues Sebastian has tagged 1.2 would be a good start.
Ok, so you would prefer proposal files with issues to just issues?
How would that look in practice? Where will these proposals end up? And the issues? What do you think about the project board idea?
Explain the value of separate files though. From a git and github perspective, all that matters is commits, ultimately.
I just added you two as collaborators on that main project.
I’ve made a few changes to the board to adopt the structure of the Roadmap project under schema.
.
One of the things I think we need to figure out how is to distinguish among different kinds of issues, and stages.
Sometimes, we have mostly instant agreement that we should support a certain feature, and then years of off-and-on conversation which comes down to differences about how to support it.
Other times, it’s straightforward to combine proposal and PR in one stage.
So we need an elegant way to deal with both.
I added some issues to the project to do. One other nice little thing is being able to read the ticket within the project UI (the right panel).
Thought: for proposal review, we don’t need a “done” column, as all this project does is review proposals, and accept or reject them.
Implementation happens in the release projects.
Possible, yes. (Actually, in the process I’ve outlined above there won’t be any items in the “done” column as accepted issues will ultimately be transfered to a release project board. Well, we could nevertheless leave them there if we want, but I’m not sure that would be useful.)
The Doom project has a “backlog” label that the maintainer uses to signal either he doesn’t have time ATM to review, or that he has, and is unsure of how to resolve. When that is no longer the situation, he removes the label.
We might use something like that as well, to essential designate a proposal can’t immediately be approved or rejected?
