Essential Strategies, Tips and Tools for Coronavirus Preparation

Questions to Ask Your Rock Partner

What to learn before retaining a Rock Partner.

Whether you’re looking for a partner to help get Rock off the ground or you’re looking for day-to-day support and customization, working with a Rock Partner can offer many advantages over working alone. Partners have deep level knowledge of how Rock works, and how to use it to best serve your organization. Understanding their services and practices will help your organization grow with Rock for years to come. Here are eight key questions that every client should ask during their partner interview.

1. How and where will you store my passwords and log-in credentials?

Passwords should always be stored in an encrypted vault. This vault should allow for centralized access control. This allows partner employees to have their access removed upon leaving.

2. Who will own the intellectual property of the projects we hire you to work on?

We recommend that you always have rights to the intellectual property of what you pay for. It's not uncommon though for the partner to also request rights to the intellectual property also. This allows them to help others down the road. The key point here is to have the conversation before signing any project documents.

3. Who is responsible for maintaining the customizations going forward?

This is another great conversation to have before signing any project documents. You'll want to know what the warranty period is for a project and who is responsible for fixing issues that might come up after updates.

4. Will you change the core blocks on my site? I understand that is not a best practice and can break my instance when I upgrade.

This is an important discussion point. In a rush to help meet your needs it can be tempting to change core blocks, clone them to new versions or apply fragile modifications. These can help you in the short run but will always come back to bite you.

Changes to core blocks will be overwritten on updates and therefore should not be done. To get around this some will clone a core block and make a custom version for you. This again is not a good idea. Splitting a core block to a custom one will keep you from getting new features applied to the original and will be much more likely to break on updates. Some developers might also resort to using CSS/Javascript to show/modify the core blocks. This too should be avoided. These types of changes are very likely to break in the future and make it very difficult to resolve in the future as issues are often hidden from view.

So, what should be done? If you require core changes to blocks a partner can request these changes for you from the core team. This gives you to comfort of knowing that you will have a change that is fully supported. It also benefits the community as now everyone gets access to your additional features.

5. Do you use source control or backups for versioning on blocks?

Partners should keep a copy of the code they write for you. This copy should include a history of all the changes using a tool called source control.

6. Do you keep track of all the changes made to my instance (from configuration to customization)?

Over time, it is likely that you will work with more than one person at your partner organization, and possibly even more than one organization. If changes to your instance aren't recorded as they are implemented, it may become impossible to recreate over time. This could lead to confusing and expensive issues if there are major deviations from core configuration and a future staff person wonders why something isn't working as expected. It is important that these changes are documented for you by the partner doing the work.

7. How will my data be stored while doing an implementation? Will it be encrypted at all times? How long past implementation will you keep a copy of my data?

When doing an implementation, a partner will need access to your data (usually in the form of an export from the original system). You'll want to ensure that your data, when not in the process of being imported, is stored in a safe digital vault. It should not remain on a laptop if it's not actively being used. When not being used it should be encrypted with a key. This key should be stored in a separate vault. A process should also be in place to delete your data after a certain number of days past implementation.

8. For mobile projects, will you deviate from the core mobile shell?

Keeping the core mobile shell (the code that runs on the mobile phone) is important to ensure stability for your applications. If the shell is changed, your mobile apps will break across Rock updates. We highly recommend that the shell be left unchanged. If new features are needed, we recommend working with the core team to add those features. This ensures quality code that aligns with the mobile strategy and allows for reuse by all churches.