Website: Decide the future of the Kubeflow "events" page

[sarahmaddox]

https://www.kubeflow.org/docs/about/events/

To consider:

• Is the docs website the right place for this page?
• How to keep it up to date? For example, should we assign all incoming issues to the Kubeflow community manager, or should we request that people send us PRs rather than issues?
• When should we remove past events, and who will do that?

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label question to this issue, with a confidence of 0.97. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: dashboard, app homepage and code for this bot.

[sarahmaddox]

I've love your comments on this, @theadactyl and @texasmichelle

/cc @theadactyl
/cc @texasmichelle

See issues:

• https://github.com/kubeflow/website/issues/616
• https://github.com/kubeflow/website/issues/455

[sarahmaddox]

@theadactyl has suggested that the community wiki would be a good place for the events page.

[texasmichelle]

SGTM! Easily editable without the overkill of requiring PRs. I'm in favor of not removing old events since it's helpful to have a record of videos and decks. Because the list is in reverse chronological order, adding a section break by year would make things a bit clearer.

To resolve this issue:

• [ ] Create a wiki page for events
• [ ] Migrate existing content from https://www.kubeflow.org/docs/about/events/
• [ ] Add a year separator
• [ ] Add guidelines for adding future events
• [ ] Remove page from kubeflow.org

[theadactyl]

I'll tackle this in docs sprint how about :)

On Wed, Jul 10, 2019 at 9:46 AM Michelle Casbon [e-mail]
wrote:

SGTM! Easily editable without the overkill of requiring PRs. I'm in favor
of not removing old events since it's helpful to have a record of videos
and decks. Because the list is in reverse chronological order, adding a
section break by year would make things a bit clearer.

To resolve this issue:

• Create a wiki page for events
• Migrate existing content from
  https://www.kubeflow.org/docs/about/events/
• Add a year separator
• Add guidelines for adding future events

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubeflow/website/issues/623?email_source=notifications&email_token=ABREJVOZQGV2N6QFYDEFUSLP6YG53A5CNFSM4HFKONJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZUB7II#issuecomment-510140321,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABREJVLQCDJIB3JILS4VMO3P6YG53ANCNFSM4HFKONJQ
.

[texasmichelle]

/assign @theadactyl

[sarahmaddox]

Great! I've added the issue to the Kanban board.

[scottilee]

@sarahmaddox I can take care of this if I can get permissions to edit https://github.com/kubeflow/website/wiki?

[sarahmaddox]

Thanks @scottilee! The plan is actually to move the info to the community wiki rather than the website wiki:
https://github.com/kubeflow/community/wiki/Kubeflow-Community-Events-&-Programs

@theadactyl can you give @scottilee access to the community wiki. (I have read access only.)

[scottilee]

@theadactyl here's the markdown you can use to create an events page that fulfills @texasmichelle requirements: https://gist.githubusercontent.com/scottilee/0b1e92c3cb67f5c02031a4f17902e826/raw/35a972beb47f58f058d3f691f0f61f901daee47a/Kubeflow-Community-Events-&-Programs.md

[jtfogarty]

/area docs
/priority p2

[sarahmaddox]

@theadactyl Looking at the history of this issue, I'm thinking that we need to define the purpose of the page before deciding where it should go and who should maintain it.

Suggestion: Let's discuss this at an upcoming Kubeflow community meeting.

• Discuss the purpose of the page - what do we want to get out of it, who is the audience, do we really need a running list of events, and how long should we keep events visible on the page. For example, should we remove events after a year?
• Decide the best location for the event info, based on the outcome of the above discussion. Maybe we don't need a page, but should publish once-off short blog posts about each event instead?
• If we do decide on a page, ask if there's anyone willing to maintain the page.
• Give that person the access rights that they need to maintain the page.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.