Proposing limiting locations for various discussions

[oddcoder]

So right now, We have many places in the project that can be used to track discussions and it can be tricky in the future to track where was certain issue/message posted.

Right now the following places were used at least once:

• The organization wide discussions(this tab)
• The issues of project-wide-discussions
• The issues of tpm-rs
• The projects tab of tpm-rs
• The projects tab of the organization.

Not all of those places are currently actively used, but they have been used before.
Would it make sense to limit the places where one can have discussions and issues to avoid fragmentation?

Normally I would have said issues are enough for tracking everything but I noticed some discussions relates to TCG meetings. So I propose keeping only two places for discussions:

• The issues of tpm-rs for anything related to the project including missing features, bugs, issues, refactoring, progress tracking, ...etc.
• The organization wide discussions for discussions that does not impact the code in anyway, such as this discussion, and meetings related discussions.

What do you all think?

[trent-reed]

Frankly I agree, one of the first difficulties I had joining this project was that there's so many ways to interact it's not easy to see which ways are the preferred ways... I'll go a step further and say that if we can (as in if there are options for it), we should entirely just turn off any of the features we aren't going to use to filter people to the appropriate places.

I also would like it if we could "close out" on discussions instead of leaving them open forever. But for discussions around codestyle or norms, we should probably summarize our our decisions someplace instead of leaving the home for that information as the discussion topic (for example, I want to close #18 and #19, but not until I have someplace that I can write a markdown doc saying "our codestyle agreement is something like this" - I'm wondering where that should be? To be clear, writing it down doesn't mean it can't change in the future or that we can't sometimes exercise leniency).

I just don't want a bunch of open discussions so I think we should resolve to close them, and I want to be able to point to things we already talked about and have a summary of the outcome, like "here's what we do about X - here's the discussion link for details"; especially for things like norms and codestyle.

---

Another possibly related topic:

Should we also talk about some of these other repos in the org? We've got 6 of them and is that really necessary? Can any of those be closed to avoid more confusion?

I think this is a good discussion, and I agree it's not fully settled yet.

[oddcoder]

Frankly I agree

Alright then, I think only @chrisfenner has administrative permission, Would it be possible to archive project-wide-discussions ? and disable projects for the whole organization?

but not until I have someplace that I can write a markdown doc saying "our codestyle agreement is something like this"

That is what https://github.com/tpm-rs/docs is for. I do agree that we should have contributing guide lines that extend beyond the style enforced by cargo fmt and cargo clippy. I already had something but I didn't upstream it because so far everyone had mutual understanding of the same unspoken rules.

Another possibly related topic:

Many of those repositories are there for organizational purposes, related to TPM as organization, but I could be wrong. I think it might be beneficial to move this to separate discussion.

[chrisfenner]

I think this is a great topic and I'm inclined to agree that we should consolidate the channels a bit. @bradlitterell what do you think?

[bradlitterell]

I think issues in any code repos are a great way to track bugs and fixes. I have no issue disabling (if possible) or (just) not using projects if we want to use only issues for tracking work. I think we have been trying to find things that work for people.

The tenets of the organization (as reflected in our organizing documents) is that most of the discussions for the project should in the open and we have been searching for what works best.

The private repos are related to the management of the TPM-RS organization itself. For example .github and .github-private are repos created by github when you create an organization and are where the TPM-RS landing page has its contents. (https://github.com/orgs/tpm-rs).

So, for the most part I think we need the private repos we have, with the possible exception of project-wide-discussions. Maybe we delete that repo and hold those discussions here in orgs/tpm-rs/discussions.

I think we probably want to keep the docs repo because someday (hopefully) there will be a full documentation site that could be published from there (as opposed to having just a docs folder in tpm-rs.

As for tracking discussions, most of them should be in a shared place that people will check.