Thanks for the information you provide. I’d like to combine the information you provide and the proposal of "planing work based on Github issues/PRs/milestone you mentioned last time” [1] together and write down a more formal solution that we can discuss and implement with little cost.
It might take me a little longer time than usual. [1] https://lists.apache.org/thread.html/043250bc9589c947721bbd703d9ce535e67f7ed0e3a1bbee22aa1f18@%3Cdev.weex.apache.org%3E <https://lists.apache.org/thread.html/043250bc9589c947721bbd703d9ce535e67f7ed0e3a1bbee22aa1f18@%3Cdev.weex.apache.org%3E> Best Regards, York Shen 申远 > 在 2019年7月16日，18:49，Jan Piotrowski <piotrow...@gmail.com> 写道： > > Issues definitely are like weeds - there are always more. > > Some unstructured thoughts: > > - Add a feature request template > - Add a support template that moves questions and debugging stuff to > Stack Overflow (if you have many of those) > - Add some more space to type into the bug report template, currently > it is very full already on start > - Try to quickly respond to new issue and ask for clarification > - For Apache Cordova asking for a new, plain project with reproduction > was a good way to move a lot of the work from committers to users: > https://github.com/apache/cordova-contribute/blob/master/create-reproduction.md > - Close issues that delete the issue template and ask them to create a new one > - Think about not supporting older versions (and debugging of problems in > them) > - Use labels to "group" or categorize issues, that way it is much > easier to just leave them open if they are for areas that are not in > focus right now > - Use milestones to "prioritize" issues. Something that is in "far > future" doesn't have to be looked at vs. something that is in "next > bugfix release" for example > - For another bug OSS project I am working on I created a habit for > myself to start every day with triaging and tagging all the new issues > that came in over night. Issues without labels are "untriaged". That > way it's 30 minutes per day to keep "up to date", and then the real > work can start > - Maybe try to communicate clearly which issues someone from the team > will tackle, and which will need someone from the community to step up > and in > - Maybe tag your issues by language - could help non-bi-lingual users > to look for issues they will understand (Currently quite frustrating > for me to open all those issues I can't even read) > > Good luck! > > Am Di., 16. Juli 2019 um 12:31 Uhr schrieb 申远 <shenyua...@gmail.com>: >> >> As you might observe, the quantity of Weex's users is huge, and there are >> around 15 to 20 new Github issues every week. It's a lot of work for me to >> verify, response and fix the issues especially some of them are in low >> quality. For example, it took me 3 hours to read all the new issues and >> close the one without reproduce procedure and verify other issues existing. >> >> I am really curious about how other Apache projects handle Github Issues. >> Is Github Issues like grass that you must weed every week? >> >> And how to encourage users to get more involved, like reading the code and >> create PRs instead of simply asking questions on Github? If we could find >> promising contributors or committers in our users continually, then we >> shall build a more healthy community. >> >> I know there are many projects around Weex, like EEUI[1], EMAS[2], etc.. >> And I even know there are books about how to write code using Weex. It's >> totally fine if one want to create its own community or project based on >> Weex, but it would be great if such projects could join the Weex community. >> >> [1] https://eeui.app/ >> [2] https://cn.aliyun.com/solution/emas >> >> Best Regards, >> YorkShen >> >> 申远
