Re: [DISCUSS] How to handle Github Issue

[York Shen]

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
 


Best Regards,
York Shen

申远

> 在 2019年7月16日，18:49，Jan Piotrowski  写道：
> 
> 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 申远 :
>> 
>> 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
>> 
>> 申远

Re: [DISCUSS] How to handle Github Issue

[Jan Piotrowski]

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 申远 :
>
> 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
>
> 申远

[DISCUSS] How to handle Github Issue

[申远]

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

申远