Determining how much time is needed to fix a bug can be tricky because a few hours may be needed to figure out the issue and only five minutes to fix it. Or we realize that their is an architectural problem, and it will require significant work. So, generally, if something looks like it's going to take a lot of time (more than is reasonable), we get back to you to discuss the priority level, potential workaround, etc. For feature development, there is similar uncertainty.
Tips to get the most value:
- Try to reproduce the problem on demo.tiki.org to detect if the source is a local configuration issue.
- Explain the issue in a way that's easy to understand and reproduce, even for someone not familiar with your project.
- Give us an indication of how important it is. It's perfectly OK to tell us "Only do if easy"
- Document the process when you learn something new about the issue https://doc.tiki.org/
- You are likely to forget and will need to come back to the documentation!
- Feature development has similar variance because we are building on existing code. Sometimes all goes smoothly, but sometimes we need to fix/change some code before we can build on it.
- Have a reasonable timeline: doing things in a rush makes it difficult to do things the right way with the right people.
- Help with testing: proper testing takes time and some clients just want someone else to take care of it all, but if you are OK to help here, you can be part of the development process.
- Make a list in a wiki page or issue tracker so we can go through it instead of sending several emails with several issues.