@wolftune and I would like use the wiki for our core documentation (values, economic theory, market research, goals, mechanism, etc) and make the wiki Gitlab project the place for tracking issues at that level (the main motivation — right now those issues have no home).
Before we fully embrace this, we’d like to get a little buy-in: @team if this sounds good, please acknowledge this post in some way. If you have questions or concerns, you can bring them up here or in Wednesday’s meeting. If you want more context, read on.
Background / Motivation
Aaron, Michael, and I have been discussing potential updates to the crowdmatching mechanism. So far we’ve had a very verbose, open-ended discussion. Now, as we start to narrow down towards specifics, we’re ready to share a more concise version of our thoughts with the team.
We planned to start that discussion by writing a post here on the forum, but ran into an issue: There isn’t really an appropriate category, either here or on GitLab (for tracking this task: writing the post). The closest is #clear-the-path:design, and while that would be technically correct, it’s a different scope of design; it’s really about the “design” of the platform overall, since it touches on topics like our mission and business plan.
Aaron and I talked about this, and decided the best place to create an issue on GitLab is probably the [wiki repo], since a lot of its content is already closely related. And if we’re going to use the wiki for these sorts of issues, it would be better if other stuff we’ve just dumped there to other, more suitable locations (drafts to GitLab issues, meeting notes to their own repo, etc). This has the added benefit of making the wiki’s search more useful — right now it has a lot of clutter, mostly due to meeting notes.
We’d shift other types of content to different locations; stuff like team member profiles, onboarding info, and meeting notes, is there because the wiki has been acting as a catch-all for stuff with no other home, not because it’s where that content belongs. This would be done gradually over time, not in a big proactive reorganization (we’ve done enough of those already…). ↩︎