inSided Information Policy, Testing and Deployment

I must say that I totally agree with you @bjoern_schulze .

We've had several cases in which we've found out about new features several days, sometimes even a week late. In most cases it's our superusers who've let us know that there's a new feature.

We also expect to be notified beforehand, preferably via mail, about all new go-lives and major fixes. We want to be able to inform our customers about these not vice versa. If new features are informed here on InSpired I expect that there would be a constant way of informing us. Meaning that there's always a go-live date in the topic title etc.

We also strongly feel that go-lives should never happen on a thursday afternoon / fridays, as that leaves too little time to fix things before the weekend. We expect that new features should only be deployed in the beginning of a work week, not at the end.

Hi Bjoern and Suvi, thanks for the honest feedback and sharing your ideas and expectations. We definitely understand your concerns. We're going to discuss this internally and see how we can improve this process. We expect to have some updates for you on this matter in the coming days.

I’m back with an update. We evaluated our release and announcement process and made the following agreements and action points:

- We’ll continue to post all product releases and announcements to the “News & platform updates” category. Subscribe to this category to get email updates whenever we post there.
- In terms of planned items the roadmap update remains the leading post that will announce the bigger themes and functionalities that the product developments are working on and can be expected in a short term. Whenever start working on something that wasn’t mentioned in the roadmap update we’ll announce it here on inSpired in the “News & platform updates” category. On top of this we will email you what is coming up and what is released on a regular base (like the community newsletter).
- For releasing the general rule of thumb will be: whenever a release has a direct impact on the behavior / design of the platform we will announce it to inSpired a couple of days prior to releasing it to your platform. We’re working on making inSpired more suitable to preview and test new functionalities, this will give you some time to get familiar with what is about to be released and prepare your communication. When we start working on one of your ideas we’ll update the idea topic with a status change and a comment. After a new release we’ll always provide an update here on inSpired and if needed a ‘How to’ guide. Bigger releases will be sent to you via an email as well.

In order to make inSpired suitable to preview and test functionalities (for the User experience) we need to make changes to our deployment process, we’ll look into that. For the long term we are investigating the possibility to show announcements and release notes directly in your Control Environment, this way you can read all the latest news and announcements directly when you log in to Control.

Thanks for the update!

- For releasing the general rule of thumb will be: whenever a release has a direct impact on the behavior / design of the platform we will announce it to inSpired a couple of days prior to releasing it to your platform. We’re working on making inSpired more suitable to preview and test new functionalities, this will give you some time to get familiar with what is about to be released and prepare your communication.
Oftentimes a customer not only needs to prepare the communication, but also needs to prepare and test other things like phrases, visuals and so on. So we think it is necessary to be able to work with these functionalities on the Staging environment before, to be prepared in the best possible way, not only in theory.
(As an example take the issue I posted in the entry post. This would have been avoided if we could have tested on Staging but it couldn't have been avoided by just looking at it here on inSpired.)

So we think it is necessary to be able to work with these functionalities on the Staging environment before, to be prepared in the best possible way, not only in theory.
Where possible we try to enable early access to your staging environment, like we did for parent category, content curation and topic helpfulness for example. This comes with a risk however, when we enable extra features on staging first the codebases (production & staging) are not fully in sync anymore. This may cause unexpected behaviour and hiccups when deploying, therefore we can't always promise early access.

- For releasing the general rule of thumb will be: whenever a release has a direct impact on the behavior / design of the platform we will announce it to inSpired a couple of days prior to releasing it to your platform. We’re working on making inSpired more suitable to preview and test new functionalities, this will give you some time to get familiar with what is about to be released and prepare your communication. When we start working on one of your ideas we’ll update the idea topic with a status change and a comment. After a new release we’ll always provide an update here on inSpired and if needed a ‘How to’ guide. Bigger releases will be sent to you via an email as well.

Thanks @Yoeri for the update :)

Question about releases - will these announcements have a set go-live time? We feel that it's super important to have a set go-live date in order to prepare for it ( and make time for testing etc.).

Question about releases - will these announcements have a set go-live time? We feel that it's super important to have a set go-live date in order to prepare for it ( and make time for testing etc.).
Yes. We aim to put a release date in these announcements. In the first announcement this can be more generic like 'end of this month', 'early June'. As we get closer to the release we can set an actual date and communicate this.

Yes. We aim to put a release date in these announcements. In the first announcement this can be more generic like 'end of this month', 'early June'. As we get closer to the release we can set an actual date and communicate this.

Great - this sounds like a plan 🙂