search

operate-first / community

GNU General Public License v3.0
11 stars 6 forks source link

Define an Operate First maturity model #86

Closed quaid closed 1 year ago

quaid commented 3 years ago

This may be something that is partially at the WG level in OpenInfra Labs, but I feel the Op1st community has the (still unwritten) charter to take care of stuff like this.

Basically the artifact of this exercise is a matrix of maturity levels (1-5?) against rows of elements of an Operate First environment.

This may exist in some format, or be adoptable from an SRE maturity model.

Some uses for this model:

billburnseh commented 3 years ago

I think this does need OI Labs participation since they are out there recruiting partners to set up clouds for this. I also think the balance between being vague and too prescriptive will be hard to get right. Vague is that the cloud needs to welcome devs and have open ops they can participate in. A lot of the rest is variable (say, a vmware based cloud, using a different upstream , using non-SRE ops, etc, etc).

quaid commented 2 years ago

Let's do a first draft here, then run it by the mailing list. @stefwalter if you want to participate in the draft or if you have anyone else who might have some thoughts?

I think we need to define:

  1. Categories of things that need to be included in order to be considering to be operating first at some level. These can be the rows in a matrix.
  2. Levels within those categories that make sense, i.e. there must be some usefulness or different to being at a level for it to count.
  3. Short definitions for the categories.

Add or change this list in your replies:

billburnseh commented 2 years ago

A key dividing line is the cloud environment. Is it anti-SLA, where the dev's can do anything, or SLA where the devs have restrictions in.

stefwalter commented 2 years ago
stefwalter commented 2 years ago

Should we work on a mindmap for this @quaid ?

billburnseh commented 2 years ago

On Fri, Nov 12, 2021 at 8:14 AM Stef Walter @.***> wrote:

  • Does the team operate the code in production before it's included into an (open source project) release?

Yes that is the idea, don't release before you have operated the code in as close to a production environment as possible. so that operational considerations can be understood and taken into account.

  • Does the team operate the code in production before it's included into a Red Hat product?

Ideally, upstream projects will adopt operating first in community cloud so that their projects are known to be suitable for use in a cloud env and all consumers of the project benefit. Of course, Red Hat always needs to ensure that it's products are enterprise quality, and operating that first is also important. I think if an upstream does not operate first then it's doubly important for Red Hat too when making a product (and of course feeding back issues found to the upstream).

  • Are contributors (non-team member) able to diagnose, change or operate the service in the same way as a typical (eg: junior) team member?

Not sure I fully understand this question. But I think yes. If someone wants to take an upstream project and bring it to a community cloud to see how it operates, I do not see any barrier (other than whatever learning curve they may have, if they have little context of the project). More likely, the project team would incorporate doing it as part of their overall release flow (not unlike having a beta cycle).

cheers, Bill

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/operate-first/community/issues/86#issuecomment-967109976, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKLLPQO2RCH3JXYCU7RHHTULUHLZANCNFSM5EGYFSHA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Bill Burns (He/Him/His) Senior Engineering Manager, Red Hat Research Operate First Initiative Red Hat https://www.redhat.com/ @.***

stefwalter commented 2 years ago

I opened this pull request to represent the minimum bar for Open Source Services.

https://github.com/operate-first/community/pull/127

I believe the minimum bar is defined by: The absolute minimum Open Source behavior that a service must achieve so that contributors are enabled to progress it further along the Operate First methodology.

sesheta commented 2 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

quaid commented 2 years ago

/remove-lifecycle stale

sesheta commented 2 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

Gregory-Pereira commented 2 years ago

I see that #127 got merged, does that mean this thread is no longer required and the discussion can take place via pull-request threads against the current state of operate-first/community or does this still need to remain open? /remove-lifecycle stale

quaid commented 2 years ago

@Gregory-Pereira we're getting there, but the definition of an Open Source service is only part of the maturity requirements. We need to keep this open and continue to define what else is needed in the model.

We may want to stop having the bot check for issue age in the community repo, if we can. The issues hanging around for a while are doing so because they are long-term goals.

sesheta commented 1 year ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

sesheta commented 1 year ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

sesheta commented 1 year ago

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

/close

sesheta commented 1 year ago

@sesheta: Closing this issue.

In response to [this](https://github.com/operate-first/community/issues/86#issuecomment-1386422376): >Rotten issues close after 30d of inactivity. >Reopen the issue with `/reopen`. >Mark the issue as fresh with `/remove-lifecycle rotten`. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.