@jflory7 filed Fedora-Council/tickets ticket #416. Discuss here and record votes and decisions in the ticket.
1 Like
The abbreviation seems unnecessarily opaque to me. When I saw the title of the ticket, I thought “commarch” was a German word for commerce or something. 
As I understand it, the goal for this repo is basically “Justin publicly tracks his work”? I’m 100% on board with that, and if that’s the goal, you can call it whatever you want. But I’d suggest community-architecture or something more obvious. It’s not like it has to be typed out very often, so saving keystrokes is a bug, not a feature.
I’m fine with this, with one modification. I’d like to see the Council-specific docs and the tickets be in the same repo. I’ve always been bothered by the fact that we have them separate in Pagure, but never enough to do anything about it. But there are enough issues that are both ticket- and docs- that it makes sense to have them combined, IMO. (Although GitLab’s cross-repo project management may make this less of an issue.)
Since the Docs team doesn’t maintain this documentation, this isn’t much of a selling point for me. I think the other reasoning is strong enough on its own.
I go back and forth on this in my head. The separate repos concept is cleaner, but it also adds additional overhead. My current position on the pendulum is that ACLs are the right place to draw docs repo boundaries. If the same people are responsible for the content, then having separate repos doesn’t add much value.
I’m not opposed to making this change, but I don’t know that it gives us much in practice.
I would absolutely read this blog post.
1 Like
This seems fine to me. I agree that “commarch” is confusing [1].
I am the one who set up a separate “tickets” repo for the Council, and I still kind of feel like there is a benefit to having Council Work separate from documentation issues… but I also see the advantage of having it in one place. Since we’ve done it one way for a long time, I can get on board with trying it the other way to see what happens. If we do move the Fedora Council tickets, I’d like to not lose the history.
Also, if we have that combined, why a separate “community-architecture”?
Moving them does come with one of the problems with using hosted Gitlab that I don’t think we have a good answer for: while you can log in with Fedora accounts, once logged in, your identity is a Gitlab account. That means that while I am @mattdm, @bcotton is @funnelfiasco, and I have no idea how to tag @jflory7.
-
I also wanted to name the community blog “commblog” and was convinced otherwise; same logic applies… ↩︎
Right.
Sure. Expanding the jargon works for me too. So, /fedora/council/community-architecture/ as the new namespace. 
Do the repositories have to share the same issue tracker, or would cross-repo PM tools in GitLab (e.g. a project board) be a better way of tracking and organizing ongoing work? This includes with simple automation in place to automatically include newly opened tickets in a backlog.
I don’t believe my proposal adds overhead because instead, it makes identifying a responsible party of this content more transparent. The namespace these new repositories would exist in is /fedora/council/about/, /fedora/council/project/, /fedora/council/engineering/, and so on. The content would still be drawn on the ACLs that they are now.
I think it adds value for two reasons:
- For maintainers: Emerging trends and areas of engagement are better measured. Filters and analysis tools are more useful and tailored when working from the repository view. (For example, with GitLab repositories, we could use a free (and Open Source) tool like Bitergia Cauldron.io to create custom reports from a specific group or sub-group of repositories.)
- For contributors: A content module is better distinguished as its own repository. The content is easier to discover. The barrier for a new contributor is reduced because they can build their own specific site with fewer dependencies on other content modules.
This would be a good to-do to track… in the new repository. 
Why not have the cake and eat it too? 
I think both are possible in GitLab. A repository for /fedora/council/tasks/ and /fedora/council/docs/ can exist, which gives a contributor a better choice for filtering the notifications they want to follow. We could use a cross-repo project board to have everything exist in one place, and ideally, this board would drive ongoing Council meeting discussion. Occasionally (e.g. monthly? or weekly?), the board would need to be triaged and reviewed, for new things that have popped up but are not yet reviewed or acknowledged.
This I’m not sure about. Do you know who the right person (or people) would be to contact about migration support? It should be possible since Pagure stores issues in a git repository, but I’m not sure whether there is already a documented or supported way to do it.
My hypothesis is that there are things I work on that might not be directly related to the Fedora Council, but are relevant to my role and what I am doing. A separate repo gives me a space to expand these tasks out and uses an open process for how I manage and prioritize my tasks. Things I am working on together with the Council would always be filed first as a Council ticket. (And if all Council repos were in GitLab, I could build a view that shows my tasks and priorities across both.)
That said, I am running this as an experiment. I might come back to you in 90 days saying that this was a bad idea and I should try something else. Or, maybe it ends up being a useful extension for FCAIC to-do management.
That is true. In Pagure, we always had the convenience of using someone’s FAS username to tag them in Pagure. But I think we are also broadening the pool that we are we working alongside now. In Pagure, the active community was mostly people who were working on or with Fedora. Although we are an open community, the Pagure userbase was mostly exclusive to the Fedora contributor community. Using a platform like GitLab, we join a larger pool of users who work across many projects.
Migrating from Pagure to GitLab would take away that convenience, but I also think we will both (1) participate in a larger ecosystem of other developer communities, and (2) encounter existing contributors in contexts they might work in outside of Fedora.
You can usually tag me with jwf 
I think the better question is: why shouldn’t they be in the same repo? The simplicity of being able to close a ticket with “closes #123” instead of “closes council-docs#123” in a commit message is a good argument for having them be in the same repo.
It does add overhead because now you have three (or more) repos to clone instead of one. And if the ACLs are the same, then there’s no reduction in administrative burden. I don’t see how having all of the repos in the council namespace makes the responsible party and more transparent than a single repo in the council namespace.
A while back, I split several program management things into multiple repos and I have some regrets about it on occasion. The practical benefits are a lot smaller than the theoretical benefits.
Given the volume of changes to these repos, I’m not sure there’s much analysis to be done.
The barrier to a local build is lower with fewer repos. Building a local preview with a single repo means you can’t verify that cross-module references work as expected. In particular, the Council and Project docs are likely to have those sorts of cross-module references. So when making a cross-module xref, you either have to build the docs-fp-o repo or you have to trust that you got it right and double-check once the live site builds.
The Infrastructure team might have something like this. For the Docs team, we mostly just decided to declare issue bankruptcy, in part because there were so many stale issues. With the Council, it’s a different story because we want to preserve record of decisions.
We can ignore it for now and point to Pagure for history, but it might be good to have a tool-independent record of these sorts of decisions (that’s a separate discussion)
Hmmm. For this, what about using a personal sub-space (like https://gitlab.com/fedora/people/mattdm) instead of “community-architecture” and the Council space?
I like the implied principle in Justin’s proposal: associate this with the role, not the person. This way, documentation on “how to ask the FCAIC to do something” can point to a place that will hopefully change very infrequently (as has proven to not be the case with FCAICs). Maybe fcaic should be the name of the bike shed in that case?
I had done something like this in Taiga with the “FPgM Working Board”, which was mostly for my benefit. It was public, but I didn’t advertise it much and there wasn’t a lot of way for folks to interact. I see Justin’s proposal as an improvement over that prototype.
That was my intention, to also figure out what a system like that could look like.
I do like community-architecture because it describes a type of work that best resembles what I do as FCAIC. Sometimes I am apprehensive that because a repo or project is named “FCAIC”, it feels exclusive to participation. (Same thing with committees.) I like community architecture because while that is something an FCAIC mostly does, it does not have to be only the FCAIC who does it.
