Considerations:

• Lead time for downstream projects/platforms to consume
• Versioning (as detailed in #4)
• Prep branches and deploy previews (either as interim releases for acceptance testing or, for sites/sandboxes, Netlify)
• Tagging, release to repos and distribution
• Security vulnerabilities (and dependency scanning)
• Coverage?
• Static analysis?
• API Docs

These will likely look different for platforms (ie. tbDEX, Web5) and component projects (where fewer guidelines will apply and project leads take more autonomy).

The audit trail of a commit log is a helpful tool for knowing what's changed, and why. Messages like "fix" with a non-trivial diff make it difficult to know the author's reasoning, and more importantly, how future devs should proceed. Often, commits are the result of some discussion in issue trackers or on Discord.

There are some slim approaches we can take to connect the dots.

Recommending we consider across TBD-stewarded projects a light convention to point commits to that extra context.

There are some easy approaches:

• Commit message of format: "Issue #XXX - [Description]"
• A de-facto existing standard like: https://www.conventionalcommits.org/en/v1.0.0/

We want to help foster that, so the tagging in method, introducing members with similar interest, etc
I've started taking note of what topics/interest specific members seem to be drawn to so i can make those introductions and move it away from us answering the community all the time to the community answering one another and developing those conversations on their own.

This is something that can happen organically over time but we should be finding a way to help

This will help alleviate some of that new contributor anxiety, and get people to their first commit faster and create that deep attachment to the project

We can work on creating a mentorship cycle where a new contributor gets paired with one person for x amount of time a (something short maybe just until you get your first commit up?) and during that time they are being taught how to mentor themselves, so eventually they will provide that mentorship for the next person.

this isn't super fleshed out but i think this would be a cool idea for us to work on

Needs:
mentor COC
mentor guidelines/styles: how to answer questions? empowering etc
mentorship to be time boxed (1month/first commit)
checkins: scheduled? or just when a question arrises
maybe every mentee agrees to become mentor? or leave it organic idk

Provide guidelines to projects for versioning guidelines:

• Branching and pre-release for acceptance testing
• Tagging
• Repositories (Go, JS/TS, etc)
• Do we need/want a repo manager (ie. JFrog)?
• Naming conventions
  • ie. 0.x.y can be not back-compat
  • After 1.x.y, back-compat
  • x, minor number, includes API additions
  • y, patch number, includes bug fixes
  • Major number breaks back-compat
  • How does wire compatibility fit in?
• How much of Semantic Versioning guidelines would we like to adopt?

Don't overthink it; get a scaffolding in place to drop Markdown and start pushing content. Can and will evolve.

Essentially putting a feedback loop in place, starting the week of the 15th (may need to move to accommodate BTC Miami) I'm going to have one on one feedback sessions with active members. However having an automated or designated place for the community to constantly give feedback is important

option for anonymous feedback as well

I don't have a firm grasp yet on what this section should be, except to outline that natural dependencies exist. When we don't inventory them, we're crunched at the end of a platform release as we discover new things that need updates or releases.

Platform releases are composed from a set of dependencies.

Develop some light guidance outlining all TDB-stewarded components and the releases and lead times those infer to deliver comprehensive docs and general OSS availability.

For instance, in the case of Web5:

• The Web5 SDK
  • DWN SDK
  • SSI SDK and WASM bindings?
• API Docs for Web5 SDK
• Quickstart runnable code
• Quickstart docs showing the code
• Quickstart downloadable "finished" index.js
• Quickstart Web5 "widget" https://github.com/TBD54566975/web5-quickstart-widgets
• TODO App https://github.com/TBD54566975/web5-tutorials
• "Build" and "Learn" section Docs

As the Web5 ecosystem grows, there will be an influx of more contributors and participates in our open source space.

We should think about how we engage with them based on several things:

• Priority (how do we determine what users input gets higher priority? Library feedback, fixing issues, etc etc)
• Who should be responding? Is it based on project owners, maybe a rotating schedule of respondents?
• Welcoming people to make contributions
• Recognizing those that have been helpful

cc @EbonyLouis

How do we want to communicate a unified vision for what our roadmap is? It's one thing to track tasks and more low-level items, but how do we want to paint a bigger picture for the community? Where will that picture live?

Deliverable: a template from DevRel providing guidance on info needed by OSE in the request.

OSE to provide an example, @frankhinek notes that TypeScript helps with lot of this. And it'll have to be iterative; ask OSE and well evolve the handoff process as we go.

General outline:

• Primary remit within DevRel
• Requirement of OSE to create a ticket, outlining docs request. Contains type definition and enough info about it to make docs.

Some of these may be implicit in a statically-typed language.

For instance from: https://developer.mozilla.org/en-US/docs/Web/API/Clipboard

DevRel is primary remit for delivery, including prose like:

Create a pathway so an active community member can become a code reviewer on a project
this will help spread out that responsibility, and also empower community members as well

We can have maybe just marks they have to hit: made x commits, etc

@EbonyLouis raised: "Can we create issue templates for all projects"?

Issue templates are done in GitHub by simple Markdown files in .github/ISSUE_TEMPLATE. We could add some starter ones to the https://github.com/TBD54566975/tbd-project-template repo, and issue PRs into existing projects.

Example of issue template:

• In use: https://github.com/TBD54566975/collaboration/issues/new?assignees=&labels=To-Be-triageD&template=-proposal----open-source-programs.md&title=%5BPROPOSAL%5D+-+Your+Idea+Here
• Backing file: https://github.com/TBD54566975/collaboration/blob/main/.github/ISSUE_TEMPLATE/-proposal----open-source-programs.md

Encompass:

• For platforms (ie. tbDEX, Web5): Docs on dev site, API docs, Tests, Quickstart, Build and Learn, Supporting Examples, Sandboxes, releases for dependencies for platforms, QA, stakeholder identification and signoff
• For component projects: API Docs, Tests

Drill into each of these, meet balance between "enough guidance for teams to have autonomy" and "comprehensive approach to delivery that's focused on user value, consistency, and repeatable process".

Outline who needs to approve blogs

• Project DRI
• Angie

This can be super elaborate like having pathways written out for different types of contributors

Types:

• non code
• code
• design
• marketing
• writing docs
• translator
• outreach
• first issue
• new to x language
• new to OS

but also on a smaller scale to start, getting how do I contribute written out in each contributor file, steps to take, labels to pay attention to. I have a task I made in asana for this and this repo we have is a great example

how to communicate: GitHub chat, weekly meetings, discord channel
where does official project talk go vs general conversation around it

As designed w/ @kirahsapong in https://hackmd.io/FZRfVQPhRXGRVkzOxThRNg

• Versioned docs; right now docs are built and deployed on main for Web5 and DWN JS SDK. They'll show breaking changes which may drift from the docs. Some discussion w/ @frankhinek and I on this here - TBD54566975/web5-js#34 (comment)

AI for this is to propose versioning of docs as part of release process for TBD stewarded projects, so developer.tbd.website can align its docs set with API Docs.

This goes back to getting community members emails which will help with other initiatives mentioned: news letter etc
I also have ideas for reworking the website to be more inviting to new community members and a landing page might be a good idea

And contain License, README, Contributing, Governance, CoC, etc from template repo:

https://github.com/TBD54566975/tbd-project-template

While the idea of everyone agreeing to and adhering to things in the Open Source Playbook is great, there's definitely things we can do to ensure that these practices are being implemented.

For example, we can use GitHub Actions to confirm the proper naming conventions are being used.

This is more or less a placeholder to come back to as we think about what things are important to us and how we want to make sure they're being respected.