Determining how much time is needed to fix a bug can be tricky because a few dozens of hours may be needed to figure out the issue and only five minutes to fix it. Or we realize that there 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.
Please keep in mind that Tiki Wiki CMS Groupware is the Free / Libre / Open Source Web Application with the most built-in features. To reach this point, Tiki has been worked on by hundreds of people, over 17 years, and is about 1 million lines of code, and thus, the developer who wrote a specific feature may very well no longer be available, and another developer must discover this part of the code.
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.