It surprises me that no one pointed it out, but your project seems like most open-source projects. If you check out some more popular open-source projects, you might find some inspiration. And I think you should forget about SCRUM and think about this from perspective of general agile.

Agile is a all about communication and collaboration. There is reason why there 2 points out of 4 in Agile Manifesto talk about it.

Individuals and interactions over processes and tools

 

Customer collaboration over contract negotiation

And the way you describe your project, it would be difficult to have face-to-face communication with everyone working on the project, something both Agile and SCRUM encourage. So first thing I would focus on is to establish communication channels for whole team (both volunteers and product committee). Things like wiki, forums, videoconferences and proper backlog, task and bug tracking system are great ways to ensure everyone knows what is happening and what needs to be done.

Second thing I would note is not to just brush around the technological parts of agile. Many believe (myself included) that they are the ones that make agile work, not the process side of things. Code review is important and most open-source work by having someone who knows the project review the commits/push to ensure high enough quality is maintained. TDD is practically given for any agile project. It ensures any changes to the code don't break the previous functionality which is even more important in your case when volunteers cannot be bothered to fix other people's errors and mistakes. It also makes code review easier because reviewer can see in tests what functionality was added and by running them he ensures the functionality actually works as intended. Continuous integration is same as TDD. It ensures the application does what is intended by allowing short feedback loop with customer/product committee.

Last thing is that I believe you should have at least few people working on the project full-time. Those people should have specific roles:

• Product owner : While it is nice you have a whole committee dedicated to this, there should be one person who is responsible for interpreting this committee's words into specification or user stories and ensuring they are properly implemented.
• Coordinator & Scrum Master : This person should be responsible for the whole process and ensuring that everyone knows about the important things happening in the project. Also, he maintains the wiki and task&bug tracking tools. If someone has a question about the project, this is first person they should ask.
• Main developer & architect : The person who knows the code best. He does the code reviews and ensures the quality of code is good enough for agile development.

It surprises me that no one pointed it out, but your project seems like most open-source projects. If you check out some more popular open-source projects, you might find some inspiration. And I think you should forget about SCRUM and think about this from perspective of general agile.

Agile is a all about communication and collaboration. There is reason why there 2 points out of 4 in Agile Manifesto talk about it.

Individuals and interactions over processes and tools

Customer collaboration over contract negotiation

And the way you describe your project, it would be difficult to have face-to-face communication with everyone working on the project, something both Agile and SCRUM encourage. So first thing I would focus on is to establish communication channels for whole team (both volunteers and product committee). Things like wiki, forums, videoconferences and proper backlog, task and bug tracking system are great ways to ensure everyone knows what is happening and what needs to be done.

Second thing I would note is not to just brush around the technological parts of agile. Many believe (myself included) that they are the ones that make agile work, not the process side of things. Code review is important and most open-source work by having someone who knows the project review the commits/push to ensure high enough quality is maintained. TDD is practically given for any agile project. It ensures any changes to the code don't break the previous functionality which is even more important in your case when volunteers cannot be bothered to fix other people's errors and mistakes. It also makes code review easier because reviewer can see in tests what functionality was added and by running them he ensures the functionality actually works as intended. Continuous integration is same as TDD. It ensures the application does what is intended by allowing short feedback loop with customer/product committee.

Last thing is that I believe you should have at least few people working on the project full-time. Those people should have specific roles:

• Product owner : While it is nice you have a whole committee dedicated to this, there should be one person who is responsible for interpreting this committee's words into specification or user stories and ensuring they are properly implemented.
• Coordinator & Scrum Master : This person should be responsible for the whole process and ensuring that everyone knows about the important things happening in the project. Also, he maintains the wiki and task&bug tracking tools. If someone has a question about the project, this is first person they should ask.
• Main developer & architect : The person who knows the code best. He does the code reviews and ensures the quality of code is good enough for agile development.