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.
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.