The idea for this document is to be a set of thoughts about the project's licensing. This is intended to establish some ground to quell concerns about projects bringing non-GPL licensed code to in, on, or around operate-first.cloud.

Questions that have or will come up:

• How does this apply to projects that are connected via an Operator?
• How does Operate First interact with permissively licensed code within its own codebase?
• Is the GPL an appropriate license for content? Wouldn't it be better to use a CC license to make it easier/possible to merge in outside CC content and to have our CC content reused by the many other CC-licensed content projects?

For review process include Hugh

This is a good task for everyone involved in the Marketing work to do at the start of their involvement. Having each person's un-influenced, honest experience and opinions is valuable at the start, so we are looking at the widest pool of understanding. (We don't want to pre-converge understanding, which can restrict the level and quality of ideas.)

Some items about the Code of Conduct to work through:

• Do we have the right CoC? (Using the one from the OpenInfra Foundation, as being part of OpenInfra Labs.)
• The CoC is not very prominent on the first page. It doesn't have to be front-and-center, but should it be more visible? Is the footer the best location for it, or should it be off one of the main menus? E.g. under a new Community top-level menu?
  • There is some value in making it visible or findable in the top-half of the page.

In PR #244 we took on the OpenInfra Foundation's existing Code of Conduct, under the assumption that it cascaded down from OpenInfra Labs.

We need to establish if OpenInfra Labs actually expects that all projects under their umbrella are using the same OIF CoC.

If not, then we as a project need to go back and review if the OIF CoC meets our needs, as written. It is not uncommon for projects to do some customization on a template code of conduct. That may be a useful exercise for us to follow.

The CoC should be visible on the website, it doesn't have to be prominent but there is not reason to bury it. So it's OK if it’s not above the fold (meaning, the top half of a webpage visible before you scroll), but having it visible on the bottom half would be good; or as an easy to find menu item.

Create a style guide to make sure to use the language of your user base (SRE/cloud ops/sysadmin, generic open source projects) wherever you talk about the development model, how to interact with the project, and so forth.

Content from the website and other materials can appear in front of an end user without the context you meant it to be in, or the context is not apparent to the reader. This means that “just a simple and clear sentence” may not make sense for some readers.

It’s OK to spell out all your acronyms on first use, explain and link to common terms, and so forth. Don’t let a too friendly/familiar, “We all know this, right?” tone make this feel like a space exclusive to, “Only for those already in the know.”

It should provide a concise, new-user friendly set of instructions that gets someone productive immediately. For this user, that means how to get their software connected into the Op1st cloud.

It should point to a subset of other documentation, with a brief description for each.

It can have a listing of all other documentation, but that may require too much maintenance.

Automating this part of the document of documents would be a good thing. It may that e.g. every document carries a specific 25 words-or-less description that is pulled into this document and parts of the website?

This involves creating a curriculum for Data Scientists from the existing materials; identifying any gaps where there is no material for a corresponding step in the path to know what material to create; and creating a curriculum page or area for this content on the website, as per the layout for the learning path part of the website.

Once there is a new front page on the website, new navigation, and there is a landing page with the curriculum, launch a social media campaign, such as:

• One video in the curriculum per tweet, with the link going to the curriculum page.
• Highlight on the front page.
• Blog post describing the course, tweet about that.

Look for corresponding rise in traffic to the target pages, and watch what traffic does from that page: start the course, look around more, etc.

This is a crucial part of how new people see the project, one of the first things many groups and people look for first is a Code of Conduct. Ours is present but very, very had to find in the footer.

Create a tracking process and metrics tooling to go forward from this baseline.

For inclusion tracking, be sure to breakdown the functional contribution areas. This helps ensure that clumps of e.g. only-Red-Hatters don’t get hidden in the tracking.

Document and track the ways the project is contributor-driven. This means, do contributors have access to all aspects of the project and the ability to have a seat at the decision making table for each aspect?

Create a project blog as a central point for short and long forms of project communications.

No project governance visible. Having a clear and transparent governance is essential to attracting contributors beyond “a circle of friends.”

Do the work to define the governance for the project. Make it inclusive of a future of a diverse contributor base, including organizational diversity. Seek to provide equal footing for any contributor regardless of their relationship to a sponsoring organization.

We need deep technical and at least one broad "what is Operate First" presentation submitted.

https://www.usenix.org/conference/srecon21/call-for-participation

Important Dates

• Proposals due: Wednesday, June 30, 2021, 11:59 pm UTC
  • Notification to presenters: Wednesday, August 4, 2021
  • Confirmation of acceptances and deadline for program materials: Tuesday, August 10, 2021
  • Pre-recorded videos due: Monday, September 13, 2021
    • If changes are needed, you will be notified as soon as possible and will need to submit your changes within one week from that date.
    • Conference start: Tuesday, October 12, 2021, 2:00 pm UTC

We need UX help for a number of areas, this one is about how to make the user feel they are in the same place (when they are) and have left to someplace else (when they do.)

We can invite SREs from Red Hat to create the first six months of calendar.

Work to shorten the project description. Create a 25/50/100/250 word version, then use the 25 word version at the top of the website in a large font with lots of whitespace, near any calls to action.

AKA marketing messaging stack

Consider de-emphasizing and boxing the calls to participate and contribute; it should be on the front page but otherwise it is distracting from attracting the userbase to make it front-and-center throughout the core outreach/marketing pages.

Boxing would mean to physically separate them on a page so that the using-user experience is still centered, and/or creating a separate page for recruiting, and link there from other parts of the site.

Establish a style guide for terminology around “release artifacts” e.g. runbooks, Jupyter notebooks, git repos, containers, config repos, gitops reps, etc. etc.

This helps with floating up to the users' and contributors' attention what is going on, in a meaningful way.

Consistency in documentation, website copy, and marketing/outreach materials.

Need to open this discussion on the mailing list and talk it through with everyone able to participate, should they choose.

Some references:

https://www.theopensourceway.org/the_open_source_way-guidebook-2.0.html#_project_and_community_governance

https://blog.mozilla.org/wp-content/uploads/2018/05/MZOTS_OS_Archetypes_report_ext_scr.pdf

https://sustainers.github.io/governance-readiness/

https://docs.google.com/spreadsheets/d/1ya_flgj83ki46genn2b-QiXPxMrDrqjmTgmKIWJgLu4/edit#gid=0

It should provide a concise, new-user friendly set of instructions that gets someone productive immediately.

It should point to a subset of other documentation, with a brief description for each.

It can have a listing of all other documentation, but that may require too much maintenance.

Automating this part of the document of documents would be a good thing. It may that e.g. every document carries a specific 25 words-or-less description that is pulled into this document and parts of the website?

Let's review the logo design with a few things in mind:

• Does it work for all the formats we need? Printed on a hat, as a favicon, etc.
• Does it convey what we intend? I.e., does it convey meaning in the design as needed?
• Do we have editable source for the logo?
• Is the logo under an appropriate license?

E.g. https://github.com/thoth-station/core/blob/master/community/help-wanted.md

Index and create an overview of the existing content on the Drive

Work to get draft to "good enough" from Google Doc stage, then draft a new glossary page for the website.

This should include:

• Technical step-by-step for how operate-first-twitter.
• Guidelines on writing copy for a tweet.
• Guidelines on hashtags.
• Steps of what to do to promote the tweet to other friendly accounts, so they can amplify (retweet) the message.

Anything a contributor needs to know should be included in the Community Handbook, and it can be community maintained used a git-based writing workflow.

Since Op1st is in many ways a meta-community handbook, this concept needs to be considered in the context of this project, rather than creating and maintaining a manual document forever.

We may need to start manually and move to more automated, as we progress.

One question is, how far can a person go as a contributor into the private/root/secret/NOC space underneath the cloud. Operate First needs to consider how to handle those interested in contributing to the projects itself, particularly on the operations side.

If contributions to Operate First itself are desired—which is strongly recommended community best practice—a central contributing guide needs to be created.

Aside from the more obvious git-based contributing method, there will arise people who want to do the hands-on work in the NOC/operations team. If that’s not currently possible, it should be put explained and put on the roadmap for fixing.

Regardless, it is strongly recommended to create an Operate First Community Handbook for documenting the contributor experience.

Anything a contributor needs to know should be included in the Community Handbook.

If anything is missing, when the curious contributor finds the answer, the responsibility is on them to open a merge request with the addition to the Community Handbook.

The Community Handbook can be written in MarkDown or AsciiDoc etc. using a git workflow for managing writing, reviews, and publishing.

Can start with the existing teams and those helped.

Help with regards to streamlining at least some of the project websites.

Make sure the core users are able to find what they are looking for and where they are within the knowledge, whether it’s their first or thousandth visit to the site.

No clear call to action on the front-page. Identify and provide a CTA for one or more user types.

Finalize our glossary, convert to markdown, and publish on operate-first.cloud

Do in repo and test live.

Seed for wireframe.

Goal is to make it easier for project members to give talks of any kind about Operate First. These slides and demos can be pulled up on a laptop to show someone, or presented in a keynote at a conference.

This can be one set of "about the project" slides, which can be married to a set of "technical how-to" slides for that kind of audience. Finally, there can be a growing set of "presentation demos" that are maintained out of various managed services, so people can pick and choose what are most appropriate for their audiences.

With a logo we can use (issue #55), we can get a sticker design (for sure) and look at some other things.

T-shirts are not recommended as standard even giveaway. They are a big logistics hassle and difficult to manage at the event for giving away.

We can do as handout/card with information and link/QR code.

Maybe we can think of something clever, like an Operate First pen (or some joke easier to get?)

Use an open decision framework, send to mailing list, engage in conversations wherever.

This task is going through some further iterations on the project message, by working from a core 25-word-max sentences, then adding additional sentences for further expansion on the key message.

This serves some purposes:

• Provide a short, 25-word message for the top-half of the main web page, to be displayed with plenty of white space to make it stand out and resonate.
• Core 250 word message is part of presentations and messaging, either in whole, part, or for reference and inspiration.
• Gives everyone a 0-floor elevator pitch—a message short enough it can be said to someone and still have time to step back out of the elevator on the ground (0) floor.
  • Borrowing this concept from sales, it's a useful short message to have at technical conferences, when introducing yourself and the project in person or on a video call, and so forth
  • It does not need to be memorized and repeated verbatim, it can and should be humanized as you speak it out.
• When accessible to a wider range of readers, it increases the chance it will get picked up and used by other parts of our related organizations/sponsors and other open source projects.

I'm going to submit a merge request for a a file where we can hack on this, perhaps in hackmd.io and/or in a Google Doc for transparent collaborative editing.

Creating menu structure

We can borrow from existing guides within the Red Hat Office of the CTO.

Full site tree and information relationship

This is a virtual conference, and we'll need these elements for our presence:

• Branding (logo, etc.)
• PDF takeaway documents
• Links to videos on YouTube
  • One needs to be a short "what is" video
• virtual swag? "Lifetime free compute!" card?

Create with a markdown template, maintain in the community repo.

• Explore Google Analytics Dashboard; see what information can be gleaned from it
• Compose document of relevant information and observations
• Brainstorm ideas of how to improve the site based on the findings (and create a separate issues for these)

Watch the video recording where Karsten presented the community audit report. Log feedback/reactions as a comment into issue #9.

Tracking issue for declarative management for GitHub:

• Migrate label management via Prow to this repo and a postsubmit job
• Create org config for peribolos and manage it via Prow postsubmit job from this repo
• Enable repo creation via peribolos from template (upstream PR needed)

Related:

• thoth-station/thoth-application#1510
• https://github.com/kubernetes/test-infra/tree/master/prow/cmd/peribolos
• https://github.com/kubernetes/test-infra/tree/master/prow/plugins/label

Not sure if we'll need the existing labels for issues, but I'm thinking we'll need ones that are specific to this repo. This issue is for listing the ideas for changes or new labels.

The MOC uplift process seems to mainly start with joining a single hour long meeting that happens twice a month. As long as the operations team needs that meeting in the uplifting process, there needs to be an intake funnel for people who are interested.

(There is actually more out there a project can do in preparation, but it's not presented as step in a funnel, and for me at least the part about going to the meeting as a step jumped out as a hurdle.)

For example:

1. The funnel can be a form that dumps to a GitHub Issue for tracking.
2. Use the issue as the nexus for discussions with the the open source developers
3. Resolve as much as possible via he issue.
4. If the meeting is needed, it is either to resolve difficult blocking issues or is pro forma and action can be taken immediately following.

Based on the initial analysis and thoughts/feedback on the operate first website from #9, make atleast one small change on the website by adding a pull request to the https://github.com/operate-first/operate-first.github.io repo

Recommendation: move the public mailing list to a neutral Operate First community branded URL (operate-first.cloud), migrating to Mailman 3 in the process with it's modern web forum UI.

Alternative: move the public mailing list to a neutral openinfralabs.org URL. May not be able to do Mailman 3 migration as they are running MM 2, which is the same major version as listman.redhat.com.

Background

Communication in an open source project benefits from an openly archived, easy to use threaded discussion platform. The classic solution is a threaded mailing list with public archives and their all-so-valuable human readable and fixed URLs for messages and discussion threads. The real-time chat interfaces with archiving have not been able to replace this functionality. Arguably the threaded discussion experience is either sufficient or superior, but the access to public archives and easy linking is not.

As it happens, we have a project mailing list, but it is underused. I reckon that not having a web interface and being on a redhat.com domain are two things that might affect adoption.

Aside from the value in conducting and archiving threaded discussions of decision making, an openly archived mailing list is a common place to make an announcement such as about a release, a feature being deprecated, part of the project restructuring itself, and any other piece of information you want the project and the general public to be able to easily read.

Look for what might be a quick try-it-out for each class of user, float that to the front of the project website.

This is dependent on refined user personas.

The material for the quickstart may exist in part or whole, and some of this is likely to be stitching together existing pieces with some new content, once we have the persona and learning pathway defined.

Look at all the ways to make it possible for interested parties to keep up with the project. Automation plus curation?

Think about the various types of users you have and what “release” they care about, then find a way to turn that information into a feed, which may need human curation for news/outreach.

There is another purpose for release management, and that is to establish and advertise to users a cadence of output for things interesting to them. We use this in outreach, support, education, and so on at the center of user attraction and expectation. A large part of open source project marketing is reviewing “what did we release”, then simplifying and amplifying that message. This is an area the project can work to improve in the quest for more users.