community

community copied to clipboard

Describe the issue

The way it is now: select portions of k/community are available via kubernetes.dev, but other portions require browsing in the repo itself.

The way it should be: any and all documentation to which contributors are expected to refer should be available via kubernetes.dev. This would include most of k/community.

Reasons for the change:

• website content is more findable than github content
• website content is better formatted/more readable than github content
• future ability to support localizations of contributor information
• manageability of links between documents

Please set aside technical discussions of how this would be implemented. The purpose of this issue is to determine what our goal is with the various pieces of information; once we have a goal, requirements will determine the implementation.

One particular question is what materials we do NOT want to expose via kubernetes.dev, and should remain as GitHub docs only. For a lot of the general areas below, specific files will probably not be exposed regardless; for example, mentoring programs might expose information pages but not mentorship templates.

Here's a list of what's in this repo currently, and thus what would need to be ported/exposed, with items that are already available through the site checked off.

• [ ] CoCC charter/materials
• [ ] Security response guidelines
• [ ] Steering Committee docs
• [x] communications guidelines/moderator docs
• [ ] contributor guide
• [ ] github management documentation
• [ ] Code for the community repo itself (hack and generator)
• [ ] events information
• [ ] mentoring programs
• [ ] SIG and WG charters, annual reports, and other information
• [ ] Elections info (currently under Events, but moving)
• [ ] chairs and techleads documentation

Please offer feedback on specific items that you're involved with and why we would or would not want to expose them via kubernetes.dev.

/sig contributor-experience /area contributor-site /assign @mrbobbytables @alisondy

attn: @parispittman @nate-double-u

@jberkus: The label(s) area/contributor-site cannot be applied, because the repository doesn't have them.

In response to this:

/sig contributor-experience /area contributor-site /assign @mrbobbytables @alisondy

attn: @parispittman @nate-double-u

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

events information

Depending on what this is, that information could also have a home in or linked from https://kubernetes.io/community/

@sftim it's primarily information around contributor summits. Given that, I'd personally love it to be mirrored in BOTH places were it possible.

to @sftim point - can we expand on what docs those are in each one. for instance - the mentoring folder has programs and operations files.

it would be good to know what the definitions are for each area of the contributor site too to better answer these questions. example: what goes in community and what goes in resources?

re: sig directories - would they be housed in k-sigs/contributor-site or would leads be instructed they can still host materials in k/community?

missing from above - chairs and tech leads documentation: https://github.com/kubernetes/community/tree/master/contributors/chairs-and-techleads

breaking down steering committee docs they are:

• community group governance (how they should do it/operations)
• annual report instructions
• charter instructions and FAQ

Let me give an example of a section that's in my particular responsibility area.

Speaking as a likely co-lead of the forming Elections subproject, I would very much like all of the doc-structured Elections content to be on the contributor site. This would also let me create additional "quick info" pages that would be useful for contributors/voters.

Elections

Expose in Contributor Site under "Resources"

• elections meta page (i.e. here's the upcoming elections, here's where you find info, link to elections.k8s.io)
• elections subproject charter (does not exist yet)
• How To Request An Election (does not exist yet)
• elections HOWTO (for election admins)

Remain Github-only

• YAML/MD files for configuring/running elections.k8s.io
• Templates for elections committees (e.g. email templates)

FWIW - while I would love to surface as much docs as possible, I think the real thing that SHOULD move to the contributor site is the contributor guide. It serves the audience that are NEW to the project and don't have any experience navigating its structure. We want to make as much as we can as easily discoverable as possible. It's also the prime target for localization, and its frustrating when people open issues in that repo for content that is here.

If we want to look more long term and surfacing as much as possible I'd go the opposite direction and turn k/community into the contributor site and completely restructure it to serve that purpose.

If we want to look more long term and surfacing as much as possible I'd go the opposite direction and turn k/community into the contributor site and completely restructure it to serve that purpose.

If that was our decision, would it derail current efforts?

If that was our decision, would it derail current efforts?

No, if we moved some content there - there isn't a reason it couldn't be moved back and still preserve git history.

re: sig directories - would they be housed in k-sigs/contributor-site or would leads be instructed they can still host materials in k/community?

@parispittman I'm really trying to separate out "what is our goal" from "how do we implement that". Let's agree on goals first before we get bogged down in the technical details.

in your example @jberkus - where would the elections docs be housed in the current site structure? will we put everything under documentation? would that create a list without a journey?

Ah, point. Original comment updated.

Is there any data on how people use the site now?

What links are the most clicked, what are the most common journeys folks take when using the contributor site.

What are the most commonly searched things.

Google analytics is setup on it, the contributors@ account is the owner and can view everything.

I would like more links from k.dev to repos, in general. But, I agree with Bob that the Contributor Guide should be on the site (so long as all the other repos are sufficiently linked). I hope that bridges the gap here.

Yeah, let's go ahead and move the contributor guide.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

/remove-lifecycle rotten

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.