Link Podcast on Website

[RichardLitt]

I feel like https://sosdesign.sustainoss.org/ should go on https://sustainers.github.io/design.

As well, I'd like to add my checklist for how to host the podcast somewhere. Should that go here, in another repo, or in another doc somewhere else?

[jwflory]

I feel like https://sosdesign.sustainoss.org/ should go on https://sustainers.github.io/design.

To this end, I opened #21.

As well, I'd like to add my checklist for how to host the podcast somewhere. Should that go here, in another repo, or in another doc somewhere else?

Good question and that relates to the same thing I asked in #16. Do we want to host podcast information here? On one hand, we could create a "hidden" category or a meta category for us to collect Working Group meta information like the podcast. But on the other hand, maybe this distracts from this project's purpose and we are putting a square peg in a round hole.

Curious what makes sense here, and if not in the Inventory, what other tools we might use to document that kind of information.

[Erioldoesdesign]

Hmm I think you could argue each point re. should podcast meta/working group info go here or not.

imo I would also love from us to move off google docs for meeting notes and onto gitbook or similar which then could also be 'connected up to the inventory. Though it is 'bloating' it's purpose of being a 'resource hub' somewhat.

Perhaps one to vote on in the design group?

[jwflory]

Hmm I think you could argue each point re. should podcast meta/working group info go here or not.

True. My first thought is to maintain a focused scope, so we do not widen the lane so much that we lose focus.

imo I would also love from us to move off google docs for meeting notes and onto gitbook or similar which then could also be 'connected up to the inventory. Though it is 'bloating' it's purpose of being a 'resource hub' somewhat.

Perhaps one to vote on in the design group?

If we were to absorb Sustain WG meta notes (e.g. notes, podcast meta, other content) into this Inventory site, I could create a new category that won't appear on the main site home page, but I could put it on the navigation menu on the top. Maybe call it an "Admin" category. There, we could have content in different groups and ways of organizing, like a nested category for the podcast, a nested category for meeting notes, and so on. It would not clutter the home page of the site and distract from the purpose of the site, but this way, it can be a useful place for us to track and document ourselves as a Working Group.

What do you think?

[jwflory]

Folding in @RichardLitt's comment in #16:

@jwflory wrote…
Whether that information belongs on this site or not is the question.

@RichardLitt wrote…
I think maybe just a GitHub repo would be easier? Not sure this needs to be for other people.

If we are open sourcing it already by adding it into a public repository, I see no reason why it can not live in a more user-friendly interface like a custom website versus a GitHub repository. I think it is also a nice step for transparency and helping to sustain our working group by putting it in a more visible place, so people can better understand what we actually do, and how.

I see two possible directions: we could use this knowledgebase site as a way to store that type of info, or we could add this type of info into the Sustain website.

[RichardLitt]

a more user-friendly interface like a custom website

I don't know, Justin. I find a custom website to much less friendly than a GitHub repo. :/ PRs having to pass checks and breaking and themes updating and packages being out of date - all of these things stress me out.

[jwflory]

@RichardLitt wrote…
I find a custom website to much less friendly than a GitHub repo.

I'm curious to know if you feel this way only for the podcast or for the knowledgebase project as a whole. This is a good opportunity for us to define a vision and mission for this project too.

I observed previously that navigating the file tree in GitHub can be intimidating for someone who is more accustomed to search or some other intranet wiki type of tool. I am biased for GitHub though as it is a tool I use often and fits into my daily workflow already.

@RichardLitt wrote…
PRs having to pass checks and breaking and themes updating and packages being out of date - all of these things stress me out.

I understand. It can be a lot for someone who is a new contributor. It is difficult to balance automation to deploy the site without manual work. Exploring if this is the way to go can be part of defining the purpose of the project in the next Working Group meeting.

[RichardLitt]

I'm curious to know if you feel this way only for the podcast or for the knowledgebase project as a whole. This is a good opportunity for us to define a vision and mission for this project too.

For the knowledge-base project as a whole.