Make this repo public?

[pawamoy]

There were some concerns expressed in the public announcement about openness of this initiative.

My initial thought was to create a space to bring together a few active contributors to the ecosystem. Obviously, if we want just a few people, access had to be restricted. Otherwise we could have done that in the public discussions already. But now that I think about it, maybe the most important part of this initiative is to have a dedicated board of discussions, not a restricted set of users.

So, what do you think of simply making this repository public? Anyone could participate, and there wouldn't be any feeling of "secrecy". I suspect most users won't ever interact here, so it kinda achieves the same thing as the "invite people on-request" strategy, which is to allow interested people to participate.

[byrnereese]

I think transparency is important, as well as bringing in diverse perspectives to help advocate for different constituencies this product is in service of. Plus, it never occurred to me that this repository and working group would remain private forever. Quite the contrary. I see this group having the most value while we get ourselves organized, and as we craft an initial plan we can then go public with. When that happens, I think we can become more aggressively open to the public.

I think it is important to acknowledge certain risks (while also acknowledging the benefits) of becoming more open -- especially early on. The principal risk being: the more people who get involved, the longer it might take to make certain decisions. Perhaps the risk of that is small, but I can say from experience, the more people we feel obligated to build consensus with, the harder consensus will be to obtain. Being small and relatively closed right now gives us the advantage of agility.

What I think is useful to figure out as a small team is how we intend to collaborate and govern ourselves. I don't want to mire this project in process, but establishing some structure is how we mitigate the risks inherent in being more public and open.

Thoughts?

---

BTW - it would be very beneficial to us to have users as part of this working group as well. Do we know people we can invite who are not developers, but end users of mkdocs?

[waylan]

I think the answer depends on what purpose this repo serves. Over the years I have contributed to a number a projects big and small. One thing that has been consistent is that larger projects have more sophisticated systems to help manage the larger number of people involved and, perhaps more importantly, allow people to focus on their assigned tasks without being overrun with information not relevant to those tasks. Therefore, it is only natural that a greater number of separate discussion forums exist the larger a project becomes.

For any project which involves a team of more than one person, there are occasions where private discussions need to happen. For example, a security issue might have been reported and should be kept private to protect users until a fix can be released. Or a discssion may need to take place about how to proceed with a difficult-to-handle user in the public forums. The moderators need to be able to speak freely without concern that the whole world is critiquing their every word as they devise an appropriate action and response that will be made public. However, the process of getting to that public response should be kept private forever. In a small team, that can happen via email or some other private medium. However, as a team gets bigger it may make more sense to use a platform where permissions can be managed.

So, what purpose does this repo serve? If it serves the purpose(s) I mention above, then it should stay private and many of the discussions already started here should probably be moved to a public forum. However, if that is not its purpose, then those private discussions would still happen elsewhere and this repo could be made public.

[tomchristie]

Thanks @waylan neatly expressed.

Having this as a mkdocs/private space for dealing with security issues and having somewhere to resolve management or conduct issues makes sense to me, yep.

should stay private and many of the discussions already started here should probably be moved to a public forum.

+1

[pawamoy]

Agreed, nicely put.

I'd favor keeping this space separate and making it public. I believe being able to manage the discussions here differently than the main ones is a strength for the team we're building. For security/conflicts, we could use a Matrix channel, or yet another private repository. For security in particular, GitHub has some interesting features. See https://github.com/mkdocs/mkdocs/security, especially security advisories https://github.com/mkdocs/mkdocs/security/advisories.