Should we manage pull requests in the coordinate_all board?

[paulpestov]

Currently we are only collecting issues on the coordinate_all project board. The main idea was to separate the administrative side from the operational side.
This way we can head towards a more plannable implementation of features especially when we creating new issues. Since we aim to have a prioritized issue backlog we could fomulate new issues with the concept of user stories in mind. Usually user stories will add value towards certain product goals and can be split up into several individual tasks.

However, there is the possibility to create a pull request without linking it to an issue. This brings several disadvantages (like redundancy in the board because multiple items would handle the same topic) and potential risks (which could lead to more open issues) but keeps the door open for contributions with "low barriers".

In any way what do you think about managing PRs in the coordinate_all board?

[bertsky]

I do think that PRs are very important items to manage themselves, but can see the problem of duplicity. How about an approach whre PRs can be added/linked manually into the board?

The bigger problem IMO is that issues/PR in external repos like https://github.com/PRImA-Research-Lab/PAGE-XML, https://github.com/UB-Mannheim/tesseract, https://github.com/UB-Mannheim/ocr-fileformat, https://github.com/UB-Mannheim/ocrd_pagetopdf, https://github.com/qurator-spk/ocrd_calamari, https://github.com/qurator-spk/ocrd_repair_inconsistencies, https://github.com/cisocrgroup/ocrd_cis, https://github.com/bertsky/ocrd_wrap, https://github.com/bertsky/workflow-configuration, https://github.com/StaatsbibliothekBerlin/ocrd_butler, and all the module project repos, cannot be managed. (This will become even more pressing when we make API changes that necessitate updating all processors.)

[paulpestov]

How about an approach whre PRs can be added/linked manually into the board?

Yes, this sound reasonable. Maybe we could also inspect such PRs and identify/create issues which that PR want to solve.

cannot be managed

As far as I understand this is nothing we can handle in the coordination project. Thank you for listing the repos, though! Maybe we could open another thread to discuss this.

[bertsky]

As far as I understand this is nothing we can handle in the coordination project. Thank you for listing the repos, though! Maybe we could open another thread to discuss this.

You mean technically (due to Kanban limits), or administratively (due to sponsor or employer policy)?

[paulpestov]

It's kind of a mixture of both but most of all I think you cannot add repos which don't belong to the organization.

[paulpestov]

There is a separate board for pull requests now. See here.

[bertsky]

Can you please make that public?

[kba]

It is now.

[paulpestov]

Sorry, I didn't want to set it on public immediately because it would create history entries in every PR.

[bertsky]

Sorry, I didn't want to set it on public immediately because it would create history entries in every PR.

I see.

Well, getting back to the original idea of adding PRs manually, I do think there are currently lots of entries that are redundant (because they are covered by an issue already), and some are irrelevant (like https://github.com/orgs/OCR-D/projects/5#card-68834228 because it is a side-branch). Moreover, having two boards instead of one defies the point IMHO. So how about adding all the relevant, non-redundant entries from coordinate_all_pr to coordinate_all now?

[paulpestov]

I do think there are currently lots of entries that are redundant (because they are covered by an issue already), and some are irrelevant

Yes, I created this board as a starting point. There is definitely more to do.

Moreover, having two boards instead of one defies the point IMHO. So how about adding all the relevant, non-redundant entries from coordinate_all_pr to coordinate_all now?

Sure, but what about the redundant ones? Should they stay in _pr board? We still want to see and keep track of them, right? So we have to become clear about the point of individual boards.

From my experience before it was desired to separate issues (user stories) that would exist on a higher level from the development itself. Is this applicable to open-source software development?