As part of a series of topics I want to cover on improving our teamwork and meetings etc.
It’s great that we’ve been keeping carry-overs from slipping through by reviewing them. However, from here on we should instead capture all concrete actions in GitLab where they can be more easily tracked and assigned.
In order to keep up with tasks, remind us of them, it makes more sense to do check-ins on task progress. That doesn’t have to be in meetings with everyone. A project-manager (for now, me as the General Manager) should be doing regular check-ins on issues. See about unassigned ones, have some chats with people about how things are going with their assignments, etc.
Maybe some part of meetings can be for simple progress reports?
The update now: I made GitLab tasks for all outstanding carry-overs from past meetings.
These GitLab tasks you made, mentioned in your “update”, can I see them? Or do I only see one if it’s been assigned to me?
Also, it sounds like you want to dump Taiga, in which case it should be pulled from the doc, replaced with GitLab task management instructions instead. Or with a link to such instructions.
Further, do you suggest that all Merge Requests should have an “Issue” or “Todo”, or can a Merge Request “capture the action” sufficiently on its own?
If I see something I’d like to immediately improve myself, creating an “Issue” first seems redundant with the faculties of a Merge Request: both can be “Open” or “Closed”, both can gave tags (if I remember right), both foster discussion, both keep track of creation dates, and so on. As far as progress reporting, an MR can be marked as a work-in-progress or not, and the discription can be edited to give a progress report, which I believe gets queued as an event under “Overview -> Activity”.
As a middle ground, could I communicate to you, you make a “Todo”, and then assign it to me?
Yes, absolutely. I suppose aside from just doing this change, we should make an issue at GitLab for doing this doc fix… but if you want to go ahead, go for it!
We certainly don’t need to be pedantic. When an issue exists, reference it with Fixes #_ in the commit message of the fix if it’s a code issue, and if (unlikely) it’s from one of the other repos, it would be e.g. fixes legal#_. But when there’s a thing to improve and no existing issue, the only reason to make an issue instead of simply fixing it is to mark it for later or for someone else or to discuss if the solution or the issue isn’t clear.
In short: MRs with no issue can be fine.
Indeed, it’s just that an MR WIP is a claim on something, so it makes it so someone else isn’t likely to pick up the issue. If the issue is something that is liable to be outstanding for a long time while work happens, it makes sense to make an issue probably… but use good judgment case-by-case, we’ll not have some programmatic rule.
While possible, this seems like something you could do yourself unless you want that help. If there’s an MR WIP, you could add a checkbox to the description. Or if there’s no issue, make one and assign it to yourself. If you don’t have adequate permissions on GitLab, let someone know and we’ll update your user. Anyone who’s clearly a real contributor (not a spammer) and has shown some understanding of the project is welcome to be able to engage with issues. That said, we’re inclined to discuss things loosely here at Discourse and only make issues when a really clear task or clearly-defined bug is identified.
Glad to get that clarification. 
That’s definitely how I feel about it, too.