It has been interesting talking with colleagues about how we best record things like meetings in the project I’m now involved in, GovStack.
To encourage contribution, volunteer contributors, especially but not exclusively, need to feel that the decision making in the project is clear and open - there should never be a difficulty in finding how decisions were made.
After years of getting used to how we do things in the large open source project close to my heart, Drupal, I very much see a meeting, like the monthly mentoring coordination meetings, as an activity that people participate in and contribute to. So, to ensure that they are given due recognition for that contribution, we place the agenda for the meeting in an issue in our issue management system, add meeting notes after the meeting, add issues for any actions and finally give contribution recognition for those that participate.
The way a lot of more traditional projects seem to do things is to add meeting agendas and minutes into a wiki, like Confluence. So far as I can figure out, just because that’s the way things are done (and I’ve never been one for doing things because that’s the way they are done, as you know…)
So, the question on my mind is; are the benefits of recording meetings in issues strong enough to outweigh the inertia of recording them in a wiki?
Comments4
I think a wiki makes the…
I think a wiki makes the most sense. Especially with the tools Confluence provides - task reports across pages, setting due dates. Tagging stakeholders, etc.
However! Drupal's toolset was different: we had docs, not really a wiki. And the wiki wasn't very rich. Issues allow credits (which no wiki does) and thereby also adds followers automatically to the issue.
In a perfect world the meeting would be cataloged in a wiki and tied to an issue for credit/recognition as a completed task.
It's a bit heavy handed in normal project day to day, but for open source it makes sense to give recognition in these ways.
The issue could also be where requests for change or more feedback are made.
In my mind, a wiki is the…
In my mind, a wiki is the place to say “how to do a thing” and an issue is where to say “what things we did”.
So, for example, I would document how to run a meeting in the wiki but I’d actually record the meeting in an issue. If an issue needs to be made anyway, to give that recognition, isn’t also editing a wiki just adding work?
It depends on the tooling. I…
It depends on the tooling. I don't think most projects outside of Drupal, would use an issue to record/catalog the meeting unless they have our same contribution credit tracking systems.
I would imagine each meeting is its own page, following a template. And it's under a parent page that generates a table of the meetings. If it's a "vanilla" wiki, like the ones on GitHub, yes it's overkill. Use an issue + labels and be done.
Again, it depends on the stack. Some teams use Notion as their wiki. It's very rich and makes it easier to capture rich information referenced in the meeting (issue links, documents, etc.) If they wanted to track contributions, then there would be an issue created.
Issues for me
Issues is the best fit with my mental model. I think of wikis as being for iterable, perfectable, persistent, representations of a certain blob of information.
Whereas in an issue there is no artifact other than the process; new information is appended as it comes in. It starts with the agenda, then maybe apologices for absence come in as comments, maybe some resources shared in the meeting get added, maybe some one writes some minutes and posts those, maybe a recording, maybe someone points out a flaw in the minutes.
I think the barrier to entry is lower with an issue, as you're just commenting, not taking the bolder step of making a permanent change to the artifact that is the wiki page.
Issues also emphasise the identity of the contributors to the record of the meeting, which seems right for a meeting, whereas wikis are more anonymous by design.