Please review and comment

Hi team!

I see many of you have privileges to access this document already, but I could use some extra eyes on this to make sure every part of the procedure is still relevant.

Can you please review this Scheduled Outage SOP for me and comment/correct the steps that might need to be corrected?

If everything looks good, please give it an approval!

Thank you so much for your help!


Why is this solely for JIRA? This should be generic.

For example, it might be necessary to bring down Talk, ID dashboard, Confluence, Atlas, or Bamboo – the downtime is (usually) minimized and procedures will need to be generic.

My question is why is this being written by you and not those on the infrastructure team? The whole document needs to have far more detail you put in there. Why is somebody with very little to no Ops experience writing things like this? When writing standard operating procedures for devops stuff, you need to go into detail. It needs to be generic.

1 Like

Hi Jeff,

I could swear those documents were all migrated out of google docs, because visibility was pretty bad.

I checked in our wiki, the same document appears to be there. I didn’t review it when migrating from google docs, is there anything specific that it was changed since the migration?

1 Like

yep. I just checked to verify and this is in the wiki so I would say this doc is OBE.

This doc is more or less not even needed. This isn’t something the public at large needs. Just in case, @chagara’s message wasn’t clear – that is what he was saying. Procedures are already in place.

1 Like

@chagara, I think you’re saying that there is already a document (on the wiki) that describes our actual SOPs. Can you share a pointer to it here for Jeff?

That’s actually the same document:

So @chagara made this document originally on google drive, and I migrated it to our wiki (as all the other documents). I’ve been making a huge effort to get more and more information to the wiki.

This is one document we didn’t make completely public because it only handles the internals of the tools we use. I’m particularly not sure what there is to comment there, because we are talking about how to setup and team calendars. If there’s any information that should be public, I’d kindly ask to create a page in, but it would be nice to ask first if no one has any security concern before that.

As I said after migrating the documents, please feel free to add trusted person to be able to read our wiki! That was the main reason why I migrated all the docs from google drive, to give more visibility.

Again, we are not sure why one of our documents is being asked to be reviewed. When there’s something wrong with one document, we just alert on telegram and edit it straightaway.

What exactly are we trying to achieve with this discussion? What is the problem we are trying to solve?

1 Like

Hey all!

Thanks for all the feedback. I didn’t create this document and I don’t entirely understand it which is why I came to you guys. I’m also struggling to find anything on the wiki that would resemble a document like this.

This document is to be used as an official SOP for OpenMRS, which I have yet to find in a similar format. So if the steps and procedures are agreed on with this document, I will use them for the official OpenMRS SOP.

@cintiadr, I followed that github link to a 404 page… is that just me?

Thanks all!

1 Like

@jeffneiman, it’s a private repository which cannot be made public unless the history is scrubbed (contains sensitive information which could compromise system security). @burke and @darius have access to the wiki.


Oh, I understand. Thanks!!!

1 Like

@jeffneiman, you’d need an account in github so any of us could grant you access (I couldn’t find your github account in your profile, so I couldn’t grant you access).

1 Like

@jeffneiman, I still don’t undestand which problem are we trying to to solve. With that understanding, it’s much easier to give you more comments and a solution.

What is an ‘official OpenMRS SOP’? Who would be the target audience of this document? If it’s only the ITSM team, I suppose there’s no reason to make it somehow any more ‘official’ than it already is, because we are only writing documents to help yourselves, and we are always changing them or improving them :smiley: While there’s quite a few guides, they have been so far maintained by us only (as we are the ones actually using them). They are not official, they are simply useful.

It’s not like we will have someone who is not part of infra team and is not actively talking to us will schedule an outage. I doubt that knowing where to click in or pingdom UI is relevant to a lot of people, but clearly some other bits might be missing.


Nobody outside of the infrastructure team should have access to production or staging servers. Staging servers are to be treated like production servers. Outages pertain to production servers(staging servers are for us to test), nobody outside of the team will be making the decision to schedule service outages – it doesn’t need to be official and should be authored by those on the infrastructure team.

I’m with @cintiadr on this. It confuses me and smells like micromanagement.

We run on the Principle of Least Privilege. Nobody needs access to production servers. Nobody should be on them when they don’t need to be. That’s how typical devops works actually.

1 Like

Guys, we’ve gone well beyond the scope of my question and we’re making assumptions based on nothing.

If this ‘process’ is accurate, we will have the @Leadership team review it for approval and securely file it away for any potential future reference, which the appropriate personnel will be handling.

Thank you for your help and your input.

Uh why do we need “approval” of our procedures? Stop treating this like a business. It’s an Open Source project.

1 Like

Why do we need management to approve it? does management even understand what is in the document?


I’m with him on this. Things haven’t changed at all. One of the reasons I left was because this is treated like a business…we’re not “personnel” – we’re volunteers…unpaid volunteers. I’m offended by this level of bull.

Has nobody noticed that there was an exodus, with me lasting the longest before I got fed up? This entire thread is indicative of this.

Keep it up and you’re gonna lose more people.

1 Like

Sure. The wiki is a git repository, every /dev/5 has access and can make a clone. If you don’t trust github backups, you can setup a cron task somewhere. There’s even all the backup strategy guide too, so pretty sure it can be included there. I don’t think it’s particularly bad to have other backups, that is actually pretty sane.

But we’ll follow any process which will make sense to us and the community, regardless of any kind of external approve.

Actually, please others vote for Outages notifications scheduling, in order for us to server better our community.


1 Like

1 Like