1.3 is out the door and by all accounts the release has been very well received (45% of you have already upgraded). As some of you may know, we had a lengthy beta period, something we haven’t done for other releases. What we found during the betas is that folks from the community helped out tremendously with testing, creating quality reproductions and participating in discussions around detailed feature design.
We’re planning to formalize an issue triage process that will enable us to keep the issues list in Github organized in a well defined and consistent way. This process would mean working with the issue author to come up with a minimal reproduction that has been confirmed by at least one other person as well as ensuring the issue is labelled correctly and contains enough information for an engineer to begin working on it. The upshot is, nailing down a process will make it possible for anyone in the community to become involved at a deeper level too.
Community help on this will free up core developer time to work on Meteor, it would give community members a way to contribute whilst getting familiar with the Meteor codebase and it will hopefully lead to a neat and tidy Github repo - something we’ve let slide more recently. Practically speaking, this would involve us writing up a crisp process on how to triage issues and make decisions in addition to giving certain Github users write access to the repository. This would be a small but important step towards enabling more active community involvement in Meteor core development.
We’d love to hear:
- If you’re interested in helping us with issue triage, please chime in with ideas.
- We’re thinking of adopting a policy where we close old issues more aggressively to keep our repo clean and make it easier to spot high priority issues. Our initial thinking is issues that don’t have a confirmed reproduction and include no activity over 30 days would be closed. What do you think about a policy like this?