You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@dubbo.apache.org by jun liu <ke...@gmail.com> on 2018/07/10 06:04:18 UTC

[Discuss]Suggestion for solve issues more quickly and effectively

Hi All, 

Now the community has become very active, pull requests and issues are being reported in a certain amount every day, in contrast, our response seems not fast enough and issues bumped up. 

I've thought of a duty table for temporarily solving this problem, committers on duty are responsible for responding to community activities, classify issues and resolve/assign issues, by doing that, we can guarantee at least some of the committers devote enough time to the community every day. 

Remember that we still need to encourage users to participate in any kind of contribution, and anyone can still participate in the community at any time.

Here’s an example duty form: https://github.com/apache/incubator-dubbo/wiki/Duty-Form
Remember label issues: https://github.com/apache/incubator-dubbo/wiki/Label-an-Issue

Do you guys have any ideas of how to achieve this goal?

Best regards,
Jun

Re:Re: [Discuss]Suggestion for solve issues more quickly and effectively

Posted by 秦金卫 <ki...@163.com>.
+1 <br/>merge PR more later, more difficult.
At 2018-07-17 21:51:34, "Huxing Zhang" <hu...@apache.org> wrote:
>On Tue, Jul 17, 2018 at 4:08 PM, Andrea Del Bene <an...@gmail.com> wrote:
>> hi!
>>
>>
>> 2. Some of issues are not clearly described, making us hard to
>>> reproduce, or reported long time ago. For these kind of issues, I
>>> think simply reply with "Thanks for your question, would you please
>>> try the latest version? I am going to close this issue now. Feel free
>>> to reopen it if the problem still exists." and close it will be fine.
>>>
>>
>>
>> In these situations it might be helpful if we ask for a quickstart project
>> (i.e. a minimal Maven project striped to the bones) reproducing the issue.
>
>Definitely yes!
>
>>
>>
>> --
>> Andrea Del Bene.
>> Apache Wicket committer.
>
>
>
>-- 
>Best Regards!
>Huxing

Re: [Discuss]Suggestion for solve issues more quickly and effectively

Posted by Huxing Zhang <hu...@apache.org>.
On Tue, Jul 17, 2018 at 4:08 PM, Andrea Del Bene <an...@gmail.com> wrote:
> hi!
>
>
> 2. Some of issues are not clearly described, making us hard to
>> reproduce, or reported long time ago. For these kind of issues, I
>> think simply reply with "Thanks for your question, would you please
>> try the latest version? I am going to close this issue now. Feel free
>> to reopen it if the problem still exists." and close it will be fine.
>>
>
>
> In these situations it might be helpful if we ask for a quickstart project
> (i.e. a minimal Maven project striped to the bones) reproducing the issue.

Definitely yes!

>
>
> --
> Andrea Del Bene.
> Apache Wicket committer.



-- 
Best Regards!
Huxing

Re: [Discuss]Suggestion for solve issues more quickly and effectively

Posted by Ian Luo <ia...@gmail.com>.
I've updated the issue report template.

On Wed, Jul 18, 2018 at 10:07 AM Ian Luo <ia...@gmail.com> wrote:

> +1, maybe we should make it clear in issue report template.
>
> On Tue, Jul 17, 2018 at 4:08 PM Andrea Del Bene <an...@gmail.com>
> wrote:
>
>> hi!
>>
>>
>> 2. Some of issues are not clearly described, making us hard to
>> > reproduce, or reported long time ago. For these kind of issues, I
>> > think simply reply with "Thanks for your question, would you please
>> > try the latest version? I am going to close this issue now. Feel free
>> > to reopen it if the problem still exists." and close it will be fine.
>> >
>>
>>
>> In these situations it might be helpful if we ask for a quickstart project
>> (i.e. a minimal Maven project striped to the bones) reproducing the issue.
>>
>>
>> --
>> Andrea Del Bene.
>> Apache Wicket committer.
>>
>

Re: [Discuss]Suggestion for solve issues more quickly and effectively

Posted by Ian Luo <ia...@gmail.com>.
+1, maybe we should make it clear in issue report template.

On Tue, Jul 17, 2018 at 4:08 PM Andrea Del Bene <an...@gmail.com>
wrote:

> hi!
>
>
> 2. Some of issues are not clearly described, making us hard to
> > reproduce, or reported long time ago. For these kind of issues, I
> > think simply reply with "Thanks for your question, would you please
> > try the latest version? I am going to close this issue now. Feel free
> > to reopen it if the problem still exists." and close it will be fine.
> >
>
>
> In these situations it might be helpful if we ask for a quickstart project
> (i.e. a minimal Maven project striped to the bones) reproducing the issue.
>
>
> --
> Andrea Del Bene.
> Apache Wicket committer.
>

Re: [Discuss]Suggestion for solve issues more quickly and effectively

Posted by Andrea Del Bene <an...@gmail.com>.
hi!


2. Some of issues are not clearly described, making us hard to
> reproduce, or reported long time ago. For these kind of issues, I
> think simply reply with "Thanks for your question, would you please
> try the latest version? I am going to close this issue now. Feel free
> to reopen it if the problem still exists." and close it will be fine.
>


In these situations it might be helpful if we ask for a quickstart project
(i.e. a minimal Maven project striped to the bones) reproducing the issue.


-- 
Andrea Del Bene.
Apache Wicket committer.

Re: [Discuss]Suggestion for solve issues more quickly and effectively

Posted by Huxing Zhang <hu...@apache.org>.
On Mon, Jul 23, 2018 at 4:57 PM, yuhang xiu <ca...@gmail.com> wrote:
> Agree ‘&READY-TO-CLOSE&’.
> Constantly try the best solution.
> :)

+1

>
> 2018-07-23 16:52 GMT+08:00 Yong Zhu <di...@gmail.com>:
>
>> On Fri, Jul 20, 2018 at 4:01 PM Huxing Zhang <hu...@apache.org> wrote:
>>
>> > Hi,
>> >
>> > On Thu, Jul 19, 2018 at 6:11 PM, yuhang xiu <ca...@gmail.com> wrote:
>> > > I think it is better.
>> > > :)
>> > >
>> > > 2018-07-19 11:04 GMT+08:00 Yong Zhu <di...@gmail.com>:
>> > >
>> > >> How about 'NEED-CLOSE' ?
>> >
>> > This keyword is not special enough, which may introduces false
>> positive[1].
>> > For examples, the following query will match some unrelated issues.
>> >
>> Right, it's not suitable. So continue to use `&READY-TO-CLOSE&` ?  Any
>> conclusions ?
>>
>> >
>> > [1]
>> > https://github.com/apache/incubator-dubbo/issues?utf8=%
>> E2%9C%93&q=is%3Aissue+is%3Aopen+NEED-CLOSE
>> >
>> > >>
>> > >> On Wed, Jul 18, 2018 at 6:38 PM yuhang xiu <ca...@gmail.com>
>> wrote:
>> > >>
>> > >> > I agree.
>> > >> > But, is '&READY-TO-CLOSE&' too long to use ?  How about a
>> abbreviation
>> > >> like
>> > >> > &RTC& or sth?
>> > >> >
>> > >> > (Sorry about last mail..)
>> > >> >
>> > >> > 2018-07-18 18:37 GMT+08:00 yuhang xiu <ca...@gmail.com>:
>> > >> >
>> > >> > > I agree.
>> > >> > > But, is '&READY-TO-CLOSE&' too long to use ?  How about a
>> > abbreviation
>> > >> > > like &RTC& or
>> > >> > >
>> > >> > > 2018-07-18 18:22 GMT+08:00 Huxing Zhang <hu...@apache.org>:
>> > >> > >
>> > >> > >> Hi,
>> > >> > >>
>> > >> > >> I just have a new idea!
>> > >> > >>
>> > >> > >> For an issue that is ready to be closed, anyone can comment with
>> > >> > >> special characters, say, &READY-TO-CLOSE&.
>> > >> > >>
>> > >> > >> So committers can search the issue with the special characters,
>> and
>> > >> > >> deal with it.
>> > >> > >>
>> > >> > >> https://github.com/apache/incubator-dubbo/issues?utf8=%E2%
>> > >> > >> 9C%93&q=is%3Aissue+is%3Aopen+%26READY-TO-CLOSE%26
>> > >> > >>
>> > >> > >> In this way, we can encourage users to check the existing issues
>> > and
>> > >> > mark
>> > >> > >> them.
>> > >> > >>
>> > >> > >> How do you think?
>> > >> > >>
>> > >> > >> On Tue, Jul 17, 2018 at 1:56 PM, Huxing Zhang <huxing@apache.org
>> >
>> > >> > wrote:
>> > >> > >> > On Tue, Jul 10, 2018 at 11:39 PM, Mark Thomas <
>> markt@apache.org>
>> > >> > wrote:
>> > >> > >> >> On 10/07/18 07:04, jun liu wrote:
>> > >> > >> >>> Hi All,
>> > >> > >> >>>
>> > >> > >> >>> Now the community has become very active, pull requests and
>> > issues
>> > >> > >> are being reported in a certain amount every day, in contrast,
>> our
>> > >> > response
>> > >> > >> seems not fast enough and issues bumped up.
>> > >> > >> >>>
>> > >> > >> >>> I've thought of a duty table for temporarily solving this
>> > problem,
>> > >> > >> committers on duty are responsible for responding to community
>> > >> > activities,
>> > >> > >> classify issues and resolve/assign issues, by doing that, we can
>> > >> > guarantee
>> > >> > >> at least some of the committers devote enough time to the
>> community
>> > >> > every
>> > >> > >> day.
>> > >> > >> >>>
>> > >> > >> >>> Remember that we still need to encourage users to participate
>> > in
>> > >> any
>> > >> > >> kind of contribution, and anyone can still participate in the
>> > >> community
>> > >> > at
>> > >> > >> any time.
>> > >> > >> >>>
>> > >> > >> >>> Here’s an example duty form: https://github.com/apache/incu
>> > >> > >> bator-dubbo/wiki/Duty-Form
>> > >> > >> >>> Remember label issues: https://github.com/apache/incu
>> > >> > >> bator-dubbo/wiki/Label-an-Issue
>> > >> > >> >>>
>> > >> > >> >>> Do you guys have any ideas of how to achieve this goal?
>> > >> > >> >>
>> > >> > >> >> Just remember that every committer is a volunteer and that
>> they
>> > get
>> > >> > to
>> > >> > >> >> choose what they work on. Allocating committers to tasks isn't
>> > >> > >> something
>> > >> > >> >> that happens on an ASF project.
>> > >> > >> >>
>> > >> > >> >> Growing the community is the obvious answer to an increasing
>> > >> backlog
>> > >> > of
>> > >> > >> >> issues. If you haven't already seen it I strongly recommend
>> > reading
>> > >> > >> this
>> > >> > >> >> post that talks about Apache Beam's experience in this area:
>> > >> > >> >>
>> > >> > >> >> https://lists.apache.org/thread.html/33a6c3aa0fffa6e961aa2b8
>> > >> > >> 61ebde333d898a5e1062d0d71d0e13d46@%3Cdev.community.apache.org%3E
>> > >> > >> >
>> > >> > >> > Hi,
>> > >> > >> >
>> > >> > >> > I agree that we can not force anyone to do anything in the
>> > project.
>> > >> > >> >
>> > >> > >> > But we can still discuss how we can clean up this issue faster.
>> > >> > >> >
>> > >> > >> > When I was reading the legacy issues recently, I've learned
>> > >> something
>> > >> > >> > that I would like to share.
>> > >> > >> >
>> > >> > >> > 1. Some of the issue are quite similar, these frequently asked
>> > >> > >> > question can be summarized to the FAQ, and I think the FAQ
>> > should be
>> > >> > >> > improved by anyone. That means the current FAQ should be put to
>> > >> > >> > somewhere other than Wiki.
>> > >> > >> > 2. Some of issues are not clearly described, making us hard to
>> > >> > >> > reproduce, or reported long time ago. For these kind of
>> issues, I
>> > >> > >> > think simply reply with "Thanks for your question, would you
>> > please
>> > >> > >> > try the latest version? I am going to close this issue now.
>> Feel
>> > >> free
>> > >> > >> > to reopen it if the problem still exists." and close it will be
>> > >> fine.
>> > >> > >> > 3. Triage the issue with labels. This make not even committers
>> > but
>> > >> > >> > contributors easily to find. For example, a label of "good
>> start
>> > >> > >> > issue" or "help wanted" may attract new users to easily jump in
>> > and
>> > >> > >> > help. I've also added to "How can I contribute" in README.
>> > >> > >> >
>> > >> > >> >
>> > >> > >> >
>> > >> > >> >
>> > >> > >> >>
>> > >> > >> >> Mark
>> > >> > >> >
>> > >> > >> >
>> > >> > >> >
>> > >> > >> > --
>> > >> > >> > Best Regards!
>> > >> > >> > Huxing
>> > >> > >>
>> > >> > >>
>> > >> > >>
>> > >> > >> --
>> > >> > >> Best Regards!
>> > >> > >> Huxing
>> > >> > >>
>> > >> > >
>> > >> > >
>> > >> >
>> > >>
>> >
>> >
>> >
>> > --
>> > Best Regards!
>> > Huxing
>> >
>>



-- 
Best Regards!
Huxing

Re: [Discuss]Suggestion for solve issues more quickly and effectively

Posted by yuhang xiu <ca...@gmail.com>.
Agree ‘&READY-TO-CLOSE&’.
Constantly try the best solution.
:)

2018-07-23 16:52 GMT+08:00 Yong Zhu <di...@gmail.com>:

> On Fri, Jul 20, 2018 at 4:01 PM Huxing Zhang <hu...@apache.org> wrote:
>
> > Hi,
> >
> > On Thu, Jul 19, 2018 at 6:11 PM, yuhang xiu <ca...@gmail.com> wrote:
> > > I think it is better.
> > > :)
> > >
> > > 2018-07-19 11:04 GMT+08:00 Yong Zhu <di...@gmail.com>:
> > >
> > >> How about 'NEED-CLOSE' ?
> >
> > This keyword is not special enough, which may introduces false
> positive[1].
> > For examples, the following query will match some unrelated issues.
> >
> Right, it's not suitable. So continue to use `&READY-TO-CLOSE&` ?  Any
> conclusions ?
>
> >
> > [1]
> > https://github.com/apache/incubator-dubbo/issues?utf8=%
> E2%9C%93&q=is%3Aissue+is%3Aopen+NEED-CLOSE
> >
> > >>
> > >> On Wed, Jul 18, 2018 at 6:38 PM yuhang xiu <ca...@gmail.com>
> wrote:
> > >>
> > >> > I agree.
> > >> > But, is '&READY-TO-CLOSE&' too long to use ?  How about a
> abbreviation
> > >> like
> > >> > &RTC& or sth?
> > >> >
> > >> > (Sorry about last mail..)
> > >> >
> > >> > 2018-07-18 18:37 GMT+08:00 yuhang xiu <ca...@gmail.com>:
> > >> >
> > >> > > I agree.
> > >> > > But, is '&READY-TO-CLOSE&' too long to use ?  How about a
> > abbreviation
> > >> > > like &RTC& or
> > >> > >
> > >> > > 2018-07-18 18:22 GMT+08:00 Huxing Zhang <hu...@apache.org>:
> > >> > >
> > >> > >> Hi,
> > >> > >>
> > >> > >> I just have a new idea!
> > >> > >>
> > >> > >> For an issue that is ready to be closed, anyone can comment with
> > >> > >> special characters, say, &READY-TO-CLOSE&.
> > >> > >>
> > >> > >> So committers can search the issue with the special characters,
> and
> > >> > >> deal with it.
> > >> > >>
> > >> > >> https://github.com/apache/incubator-dubbo/issues?utf8=%E2%
> > >> > >> 9C%93&q=is%3Aissue+is%3Aopen+%26READY-TO-CLOSE%26
> > >> > >>
> > >> > >> In this way, we can encourage users to check the existing issues
> > and
> > >> > mark
> > >> > >> them.
> > >> > >>
> > >> > >> How do you think?
> > >> > >>
> > >> > >> On Tue, Jul 17, 2018 at 1:56 PM, Huxing Zhang <huxing@apache.org
> >
> > >> > wrote:
> > >> > >> > On Tue, Jul 10, 2018 at 11:39 PM, Mark Thomas <
> markt@apache.org>
> > >> > wrote:
> > >> > >> >> On 10/07/18 07:04, jun liu wrote:
> > >> > >> >>> Hi All,
> > >> > >> >>>
> > >> > >> >>> Now the community has become very active, pull requests and
> > issues
> > >> > >> are being reported in a certain amount every day, in contrast,
> our
> > >> > response
> > >> > >> seems not fast enough and issues bumped up.
> > >> > >> >>>
> > >> > >> >>> I've thought of a duty table for temporarily solving this
> > problem,
> > >> > >> committers on duty are responsible for responding to community
> > >> > activities,
> > >> > >> classify issues and resolve/assign issues, by doing that, we can
> > >> > guarantee
> > >> > >> at least some of the committers devote enough time to the
> community
> > >> > every
> > >> > >> day.
> > >> > >> >>>
> > >> > >> >>> Remember that we still need to encourage users to participate
> > in
> > >> any
> > >> > >> kind of contribution, and anyone can still participate in the
> > >> community
> > >> > at
> > >> > >> any time.
> > >> > >> >>>
> > >> > >> >>> Here’s an example duty form: https://github.com/apache/incu
> > >> > >> bator-dubbo/wiki/Duty-Form
> > >> > >> >>> Remember label issues: https://github.com/apache/incu
> > >> > >> bator-dubbo/wiki/Label-an-Issue
> > >> > >> >>>
> > >> > >> >>> Do you guys have any ideas of how to achieve this goal?
> > >> > >> >>
> > >> > >> >> Just remember that every committer is a volunteer and that
> they
> > get
> > >> > to
> > >> > >> >> choose what they work on. Allocating committers to tasks isn't
> > >> > >> something
> > >> > >> >> that happens on an ASF project.
> > >> > >> >>
> > >> > >> >> Growing the community is the obvious answer to an increasing
> > >> backlog
> > >> > of
> > >> > >> >> issues. If you haven't already seen it I strongly recommend
> > reading
> > >> > >> this
> > >> > >> >> post that talks about Apache Beam's experience in this area:
> > >> > >> >>
> > >> > >> >> https://lists.apache.org/thread.html/33a6c3aa0fffa6e961aa2b8
> > >> > >> 61ebde333d898a5e1062d0d71d0e13d46@%3Cdev.community.apache.org%3E
> > >> > >> >
> > >> > >> > Hi,
> > >> > >> >
> > >> > >> > I agree that we can not force anyone to do anything in the
> > project.
> > >> > >> >
> > >> > >> > But we can still discuss how we can clean up this issue faster.
> > >> > >> >
> > >> > >> > When I was reading the legacy issues recently, I've learned
> > >> something
> > >> > >> > that I would like to share.
> > >> > >> >
> > >> > >> > 1. Some of the issue are quite similar, these frequently asked
> > >> > >> > question can be summarized to the FAQ, and I think the FAQ
> > should be
> > >> > >> > improved by anyone. That means the current FAQ should be put to
> > >> > >> > somewhere other than Wiki.
> > >> > >> > 2. Some of issues are not clearly described, making us hard to
> > >> > >> > reproduce, or reported long time ago. For these kind of
> issues, I
> > >> > >> > think simply reply with "Thanks for your question, would you
> > please
> > >> > >> > try the latest version? I am going to close this issue now.
> Feel
> > >> free
> > >> > >> > to reopen it if the problem still exists." and close it will be
> > >> fine.
> > >> > >> > 3. Triage the issue with labels. This make not even committers
> > but
> > >> > >> > contributors easily to find. For example, a label of "good
> start
> > >> > >> > issue" or "help wanted" may attract new users to easily jump in
> > and
> > >> > >> > help. I've also added to "How can I contribute" in README.
> > >> > >> >
> > >> > >> >
> > >> > >> >
> > >> > >> >
> > >> > >> >>
> > >> > >> >> Mark
> > >> > >> >
> > >> > >> >
> > >> > >> >
> > >> > >> > --
> > >> > >> > Best Regards!
> > >> > >> > Huxing
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >> --
> > >> > >> Best Regards!
> > >> > >> Huxing
> > >> > >>
> > >> > >
> > >> > >
> > >> >
> > >>
> >
> >
> >
> > --
> > Best Regards!
> > Huxing
> >
>

Re: [Discuss]Suggestion for solve issues more quickly and effectively

Posted by Yong Zhu <di...@gmail.com>.
On Fri, Jul 20, 2018 at 4:01 PM Huxing Zhang <hu...@apache.org> wrote:

> Hi,
>
> On Thu, Jul 19, 2018 at 6:11 PM, yuhang xiu <ca...@gmail.com> wrote:
> > I think it is better.
> > :)
> >
> > 2018-07-19 11:04 GMT+08:00 Yong Zhu <di...@gmail.com>:
> >
> >> How about 'NEED-CLOSE' ?
>
> This keyword is not special enough, which may introduces false positive[1].
> For examples, the following query will match some unrelated issues.
>
Right, it's not suitable. So continue to use `&READY-TO-CLOSE&` ?  Any
conclusions ?

>
> [1]
> https://github.com/apache/incubator-dubbo/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+NEED-CLOSE
>
> >>
> >> On Wed, Jul 18, 2018 at 6:38 PM yuhang xiu <ca...@gmail.com> wrote:
> >>
> >> > I agree.
> >> > But, is '&READY-TO-CLOSE&' too long to use ?  How about a abbreviation
> >> like
> >> > &RTC& or sth?
> >> >
> >> > (Sorry about last mail..)
> >> >
> >> > 2018-07-18 18:37 GMT+08:00 yuhang xiu <ca...@gmail.com>:
> >> >
> >> > > I agree.
> >> > > But, is '&READY-TO-CLOSE&' too long to use ?  How about a
> abbreviation
> >> > > like &RTC& or
> >> > >
> >> > > 2018-07-18 18:22 GMT+08:00 Huxing Zhang <hu...@apache.org>:
> >> > >
> >> > >> Hi,
> >> > >>
> >> > >> I just have a new idea!
> >> > >>
> >> > >> For an issue that is ready to be closed, anyone can comment with
> >> > >> special characters, say, &READY-TO-CLOSE&.
> >> > >>
> >> > >> So committers can search the issue with the special characters, and
> >> > >> deal with it.
> >> > >>
> >> > >> https://github.com/apache/incubator-dubbo/issues?utf8=%E2%
> >> > >> 9C%93&q=is%3Aissue+is%3Aopen+%26READY-TO-CLOSE%26
> >> > >>
> >> > >> In this way, we can encourage users to check the existing issues
> and
> >> > mark
> >> > >> them.
> >> > >>
> >> > >> How do you think?
> >> > >>
> >> > >> On Tue, Jul 17, 2018 at 1:56 PM, Huxing Zhang <hu...@apache.org>
> >> > wrote:
> >> > >> > On Tue, Jul 10, 2018 at 11:39 PM, Mark Thomas <ma...@apache.org>
> >> > wrote:
> >> > >> >> On 10/07/18 07:04, jun liu wrote:
> >> > >> >>> Hi All,
> >> > >> >>>
> >> > >> >>> Now the community has become very active, pull requests and
> issues
> >> > >> are being reported in a certain amount every day, in contrast, our
> >> > response
> >> > >> seems not fast enough and issues bumped up.
> >> > >> >>>
> >> > >> >>> I've thought of a duty table for temporarily solving this
> problem,
> >> > >> committers on duty are responsible for responding to community
> >> > activities,
> >> > >> classify issues and resolve/assign issues, by doing that, we can
> >> > guarantee
> >> > >> at least some of the committers devote enough time to the community
> >> > every
> >> > >> day.
> >> > >> >>>
> >> > >> >>> Remember that we still need to encourage users to participate
> in
> >> any
> >> > >> kind of contribution, and anyone can still participate in the
> >> community
> >> > at
> >> > >> any time.
> >> > >> >>>
> >> > >> >>> Here’s an example duty form: https://github.com/apache/incu
> >> > >> bator-dubbo/wiki/Duty-Form
> >> > >> >>> Remember label issues: https://github.com/apache/incu
> >> > >> bator-dubbo/wiki/Label-an-Issue
> >> > >> >>>
> >> > >> >>> Do you guys have any ideas of how to achieve this goal?
> >> > >> >>
> >> > >> >> Just remember that every committer is a volunteer and that they
> get
> >> > to
> >> > >> >> choose what they work on. Allocating committers to tasks isn't
> >> > >> something
> >> > >> >> that happens on an ASF project.
> >> > >> >>
> >> > >> >> Growing the community is the obvious answer to an increasing
> >> backlog
> >> > of
> >> > >> >> issues. If you haven't already seen it I strongly recommend
> reading
> >> > >> this
> >> > >> >> post that talks about Apache Beam's experience in this area:
> >> > >> >>
> >> > >> >> https://lists.apache.org/thread.html/33a6c3aa0fffa6e961aa2b8
> >> > >> 61ebde333d898a5e1062d0d71d0e13d46@%3Cdev.community.apache.org%3E
> >> > >> >
> >> > >> > Hi,
> >> > >> >
> >> > >> > I agree that we can not force anyone to do anything in the
> project.
> >> > >> >
> >> > >> > But we can still discuss how we can clean up this issue faster.
> >> > >> >
> >> > >> > When I was reading the legacy issues recently, I've learned
> >> something
> >> > >> > that I would like to share.
> >> > >> >
> >> > >> > 1. Some of the issue are quite similar, these frequently asked
> >> > >> > question can be summarized to the FAQ, and I think the FAQ
> should be
> >> > >> > improved by anyone. That means the current FAQ should be put to
> >> > >> > somewhere other than Wiki.
> >> > >> > 2. Some of issues are not clearly described, making us hard to
> >> > >> > reproduce, or reported long time ago. For these kind of issues, I
> >> > >> > think simply reply with "Thanks for your question, would you
> please
> >> > >> > try the latest version? I am going to close this issue now. Feel
> >> free
> >> > >> > to reopen it if the problem still exists." and close it will be
> >> fine.
> >> > >> > 3. Triage the issue with labels. This make not even committers
> but
> >> > >> > contributors easily to find. For example, a label of "good start
> >> > >> > issue" or "help wanted" may attract new users to easily jump in
> and
> >> > >> > help. I've also added to "How can I contribute" in README.
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> >>
> >> > >> >> Mark
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> > --
> >> > >> > Best Regards!
> >> > >> > Huxing
> >> > >>
> >> > >>
> >> > >>
> >> > >> --
> >> > >> Best Regards!
> >> > >> Huxing
> >> > >>
> >> > >
> >> > >
> >> >
> >>
>
>
>
> --
> Best Regards!
> Huxing
>

Re: [Discuss]Suggestion for solve issues more quickly and effectively

Posted by yuhang xiu <ca...@gmail.com>.
Seems it difficult to solve..
Maybe directly @ committers?

2018-07-20 16:00 GMT+08:00 Huxing Zhang <hu...@apache.org>:

> Hi,
>
> On Thu, Jul 19, 2018 at 6:11 PM, yuhang xiu <ca...@gmail.com> wrote:
> > I think it is better.
> > :)
> >
> > 2018-07-19 11:04 GMT+08:00 Yong Zhu <di...@gmail.com>:
> >
> >> How about 'NEED-CLOSE' ?
>
> This keyword is not special enough, which may introduces false positive[1].
> For examples, the following query will match some unrelated issues.
>
> [1] https://github.com/apache/incubator-dubbo/issues?utf8=%
> E2%9C%93&q=is%3Aissue+is%3Aopen+NEED-CLOSE
>
> >>
> >> On Wed, Jul 18, 2018 at 6:38 PM yuhang xiu <ca...@gmail.com> wrote:
> >>
> >> > I agree.
> >> > But, is '&READY-TO-CLOSE&' too long to use ?  How about a abbreviation
> >> like
> >> > &RTC& or sth?
> >> >
> >> > (Sorry about last mail..)
> >> >
> >> > 2018-07-18 18:37 GMT+08:00 yuhang xiu <ca...@gmail.com>:
> >> >
> >> > > I agree.
> >> > > But, is '&READY-TO-CLOSE&' too long to use ?  How about a
> abbreviation
> >> > > like &RTC& or
> >> > >
> >> > > 2018-07-18 18:22 GMT+08:00 Huxing Zhang <hu...@apache.org>:
> >> > >
> >> > >> Hi,
> >> > >>
> >> > >> I just have a new idea!
> >> > >>
> >> > >> For an issue that is ready to be closed, anyone can comment with
> >> > >> special characters, say, &READY-TO-CLOSE&.
> >> > >>
> >> > >> So committers can search the issue with the special characters, and
> >> > >> deal with it.
> >> > >>
> >> > >> https://github.com/apache/incubator-dubbo/issues?utf8=%E2%
> >> > >> 9C%93&q=is%3Aissue+is%3Aopen+%26READY-TO-CLOSE%26
> >> > >>
> >> > >> In this way, we can encourage users to check the existing issues
> and
> >> > mark
> >> > >> them.
> >> > >>
> >> > >> How do you think?
> >> > >>
> >> > >> On Tue, Jul 17, 2018 at 1:56 PM, Huxing Zhang <hu...@apache.org>
> >> > wrote:
> >> > >> > On Tue, Jul 10, 2018 at 11:39 PM, Mark Thomas <ma...@apache.org>
> >> > wrote:
> >> > >> >> On 10/07/18 07:04, jun liu wrote:
> >> > >> >>> Hi All,
> >> > >> >>>
> >> > >> >>> Now the community has become very active, pull requests and
> issues
> >> > >> are being reported in a certain amount every day, in contrast, our
> >> > response
> >> > >> seems not fast enough and issues bumped up.
> >> > >> >>>
> >> > >> >>> I've thought of a duty table for temporarily solving this
> problem,
> >> > >> committers on duty are responsible for responding to community
> >> > activities,
> >> > >> classify issues and resolve/assign issues, by doing that, we can
> >> > guarantee
> >> > >> at least some of the committers devote enough time to the community
> >> > every
> >> > >> day.
> >> > >> >>>
> >> > >> >>> Remember that we still need to encourage users to participate
> in
> >> any
> >> > >> kind of contribution, and anyone can still participate in the
> >> community
> >> > at
> >> > >> any time.
> >> > >> >>>
> >> > >> >>> Here’s an example duty form: https://github.com/apache/incu
> >> > >> bator-dubbo/wiki/Duty-Form
> >> > >> >>> Remember label issues: https://github.com/apache/incu
> >> > >> bator-dubbo/wiki/Label-an-Issue
> >> > >> >>>
> >> > >> >>> Do you guys have any ideas of how to achieve this goal?
> >> > >> >>
> >> > >> >> Just remember that every committer is a volunteer and that they
> get
> >> > to
> >> > >> >> choose what they work on. Allocating committers to tasks isn't
> >> > >> something
> >> > >> >> that happens on an ASF project.
> >> > >> >>
> >> > >> >> Growing the community is the obvious answer to an increasing
> >> backlog
> >> > of
> >> > >> >> issues. If you haven't already seen it I strongly recommend
> reading
> >> > >> this
> >> > >> >> post that talks about Apache Beam's experience in this area:
> >> > >> >>
> >> > >> >> https://lists.apache.org/thread.html/33a6c3aa0fffa6e961aa2b8
> >> > >> 61ebde333d898a5e1062d0d71d0e13d46@%3Cdev.community.apache.org%3E
> >> > >> >
> >> > >> > Hi,
> >> > >> >
> >> > >> > I agree that we can not force anyone to do anything in the
> project.
> >> > >> >
> >> > >> > But we can still discuss how we can clean up this issue faster.
> >> > >> >
> >> > >> > When I was reading the legacy issues recently, I've learned
> >> something
> >> > >> > that I would like to share.
> >> > >> >
> >> > >> > 1. Some of the issue are quite similar, these frequently asked
> >> > >> > question can be summarized to the FAQ, and I think the FAQ
> should be
> >> > >> > improved by anyone. That means the current FAQ should be put to
> >> > >> > somewhere other than Wiki.
> >> > >> > 2. Some of issues are not clearly described, making us hard to
> >> > >> > reproduce, or reported long time ago. For these kind of issues, I
> >> > >> > think simply reply with "Thanks for your question, would you
> please
> >> > >> > try the latest version? I am going to close this issue now. Feel
> >> free
> >> > >> > to reopen it if the problem still exists." and close it will be
> >> fine.
> >> > >> > 3. Triage the issue with labels. This make not even committers
> but
> >> > >> > contributors easily to find. For example, a label of "good start
> >> > >> > issue" or "help wanted" may attract new users to easily jump in
> and
> >> > >> > help. I've also added to "How can I contribute" in README.
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> >>
> >> > >> >> Mark
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> > --
> >> > >> > Best Regards!
> >> > >> > Huxing
> >> > >>
> >> > >>
> >> > >>
> >> > >> --
> >> > >> Best Regards!
> >> > >> Huxing
> >> > >>
> >> > >
> >> > >
> >> >
> >>
>
>
>
> --
> Best Regards!
> Huxing
>

Re: [Discuss]Suggestion for solve issues more quickly and effectively

Posted by Huxing Zhang <hu...@apache.org>.
Hi,

On Thu, Jul 19, 2018 at 6:11 PM, yuhang xiu <ca...@gmail.com> wrote:
> I think it is better.
> :)
>
> 2018-07-19 11:04 GMT+08:00 Yong Zhu <di...@gmail.com>:
>
>> How about 'NEED-CLOSE' ?

This keyword is not special enough, which may introduces false positive[1].
For examples, the following query will match some unrelated issues.

[1] https://github.com/apache/incubator-dubbo/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+NEED-CLOSE

>>
>> On Wed, Jul 18, 2018 at 6:38 PM yuhang xiu <ca...@gmail.com> wrote:
>>
>> > I agree.
>> > But, is '&READY-TO-CLOSE&' too long to use ?  How about a abbreviation
>> like
>> > &RTC& or sth?
>> >
>> > (Sorry about last mail..)
>> >
>> > 2018-07-18 18:37 GMT+08:00 yuhang xiu <ca...@gmail.com>:
>> >
>> > > I agree.
>> > > But, is '&READY-TO-CLOSE&' too long to use ?  How about a abbreviation
>> > > like &RTC& or
>> > >
>> > > 2018-07-18 18:22 GMT+08:00 Huxing Zhang <hu...@apache.org>:
>> > >
>> > >> Hi,
>> > >>
>> > >> I just have a new idea!
>> > >>
>> > >> For an issue that is ready to be closed, anyone can comment with
>> > >> special characters, say, &READY-TO-CLOSE&.
>> > >>
>> > >> So committers can search the issue with the special characters, and
>> > >> deal with it.
>> > >>
>> > >> https://github.com/apache/incubator-dubbo/issues?utf8=%E2%
>> > >> 9C%93&q=is%3Aissue+is%3Aopen+%26READY-TO-CLOSE%26
>> > >>
>> > >> In this way, we can encourage users to check the existing issues and
>> > mark
>> > >> them.
>> > >>
>> > >> How do you think?
>> > >>
>> > >> On Tue, Jul 17, 2018 at 1:56 PM, Huxing Zhang <hu...@apache.org>
>> > wrote:
>> > >> > On Tue, Jul 10, 2018 at 11:39 PM, Mark Thomas <ma...@apache.org>
>> > wrote:
>> > >> >> On 10/07/18 07:04, jun liu wrote:
>> > >> >>> Hi All,
>> > >> >>>
>> > >> >>> Now the community has become very active, pull requests and issues
>> > >> are being reported in a certain amount every day, in contrast, our
>> > response
>> > >> seems not fast enough and issues bumped up.
>> > >> >>>
>> > >> >>> I've thought of a duty table for temporarily solving this problem,
>> > >> committers on duty are responsible for responding to community
>> > activities,
>> > >> classify issues and resolve/assign issues, by doing that, we can
>> > guarantee
>> > >> at least some of the committers devote enough time to the community
>> > every
>> > >> day.
>> > >> >>>
>> > >> >>> Remember that we still need to encourage users to participate in
>> any
>> > >> kind of contribution, and anyone can still participate in the
>> community
>> > at
>> > >> any time.
>> > >> >>>
>> > >> >>> Here’s an example duty form: https://github.com/apache/incu
>> > >> bator-dubbo/wiki/Duty-Form
>> > >> >>> Remember label issues: https://github.com/apache/incu
>> > >> bator-dubbo/wiki/Label-an-Issue
>> > >> >>>
>> > >> >>> Do you guys have any ideas of how to achieve this goal?
>> > >> >>
>> > >> >> Just remember that every committer is a volunteer and that they get
>> > to
>> > >> >> choose what they work on. Allocating committers to tasks isn't
>> > >> something
>> > >> >> that happens on an ASF project.
>> > >> >>
>> > >> >> Growing the community is the obvious answer to an increasing
>> backlog
>> > of
>> > >> >> issues. If you haven't already seen it I strongly recommend reading
>> > >> this
>> > >> >> post that talks about Apache Beam's experience in this area:
>> > >> >>
>> > >> >> https://lists.apache.org/thread.html/33a6c3aa0fffa6e961aa2b8
>> > >> 61ebde333d898a5e1062d0d71d0e13d46@%3Cdev.community.apache.org%3E
>> > >> >
>> > >> > Hi,
>> > >> >
>> > >> > I agree that we can not force anyone to do anything in the project.
>> > >> >
>> > >> > But we can still discuss how we can clean up this issue faster.
>> > >> >
>> > >> > When I was reading the legacy issues recently, I've learned
>> something
>> > >> > that I would like to share.
>> > >> >
>> > >> > 1. Some of the issue are quite similar, these frequently asked
>> > >> > question can be summarized to the FAQ, and I think the FAQ should be
>> > >> > improved by anyone. That means the current FAQ should be put to
>> > >> > somewhere other than Wiki.
>> > >> > 2. Some of issues are not clearly described, making us hard to
>> > >> > reproduce, or reported long time ago. For these kind of issues, I
>> > >> > think simply reply with "Thanks for your question, would you please
>> > >> > try the latest version? I am going to close this issue now. Feel
>> free
>> > >> > to reopen it if the problem still exists." and close it will be
>> fine.
>> > >> > 3. Triage the issue with labels. This make not even committers but
>> > >> > contributors easily to find. For example, a label of "good start
>> > >> > issue" or "help wanted" may attract new users to easily jump in and
>> > >> > help. I've also added to "How can I contribute" in README.
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >>
>> > >> >> Mark
>> > >> >
>> > >> >
>> > >> >
>> > >> > --
>> > >> > Best Regards!
>> > >> > Huxing
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> Best Regards!
>> > >> Huxing
>> > >>
>> > >
>> > >
>> >
>>



-- 
Best Regards!
Huxing

Re: [Discuss]Suggestion for solve issues more quickly and effectively

Posted by yuhang xiu <ca...@gmail.com>.
I think it is better.
:)

2018-07-19 11:04 GMT+08:00 Yong Zhu <di...@gmail.com>:

> How about 'NEED-CLOSE' ?
>
> On Wed, Jul 18, 2018 at 6:38 PM yuhang xiu <ca...@gmail.com> wrote:
>
> > I agree.
> > But, is '&READY-TO-CLOSE&' too long to use ?  How about a abbreviation
> like
> > &RTC& or sth?
> >
> > (Sorry about last mail..)
> >
> > 2018-07-18 18:37 GMT+08:00 yuhang xiu <ca...@gmail.com>:
> >
> > > I agree.
> > > But, is '&READY-TO-CLOSE&' too long to use ?  How about a abbreviation
> > > like &RTC& or
> > >
> > > 2018-07-18 18:22 GMT+08:00 Huxing Zhang <hu...@apache.org>:
> > >
> > >> Hi,
> > >>
> > >> I just have a new idea!
> > >>
> > >> For an issue that is ready to be closed, anyone can comment with
> > >> special characters, say, &READY-TO-CLOSE&.
> > >>
> > >> So committers can search the issue with the special characters, and
> > >> deal with it.
> > >>
> > >> https://github.com/apache/incubator-dubbo/issues?utf8=%E2%
> > >> 9C%93&q=is%3Aissue+is%3Aopen+%26READY-TO-CLOSE%26
> > >>
> > >> In this way, we can encourage users to check the existing issues and
> > mark
> > >> them.
> > >>
> > >> How do you think?
> > >>
> > >> On Tue, Jul 17, 2018 at 1:56 PM, Huxing Zhang <hu...@apache.org>
> > wrote:
> > >> > On Tue, Jul 10, 2018 at 11:39 PM, Mark Thomas <ma...@apache.org>
> > wrote:
> > >> >> On 10/07/18 07:04, jun liu wrote:
> > >> >>> Hi All,
> > >> >>>
> > >> >>> Now the community has become very active, pull requests and issues
> > >> are being reported in a certain amount every day, in contrast, our
> > response
> > >> seems not fast enough and issues bumped up.
> > >> >>>
> > >> >>> I've thought of a duty table for temporarily solving this problem,
> > >> committers on duty are responsible for responding to community
> > activities,
> > >> classify issues and resolve/assign issues, by doing that, we can
> > guarantee
> > >> at least some of the committers devote enough time to the community
> > every
> > >> day.
> > >> >>>
> > >> >>> Remember that we still need to encourage users to participate in
> any
> > >> kind of contribution, and anyone can still participate in the
> community
> > at
> > >> any time.
> > >> >>>
> > >> >>> Here’s an example duty form: https://github.com/apache/incu
> > >> bator-dubbo/wiki/Duty-Form
> > >> >>> Remember label issues: https://github.com/apache/incu
> > >> bator-dubbo/wiki/Label-an-Issue
> > >> >>>
> > >> >>> Do you guys have any ideas of how to achieve this goal?
> > >> >>
> > >> >> Just remember that every committer is a volunteer and that they get
> > to
> > >> >> choose what they work on. Allocating committers to tasks isn't
> > >> something
> > >> >> that happens on an ASF project.
> > >> >>
> > >> >> Growing the community is the obvious answer to an increasing
> backlog
> > of
> > >> >> issues. If you haven't already seen it I strongly recommend reading
> > >> this
> > >> >> post that talks about Apache Beam's experience in this area:
> > >> >>
> > >> >> https://lists.apache.org/thread.html/33a6c3aa0fffa6e961aa2b8
> > >> 61ebde333d898a5e1062d0d71d0e13d46@%3Cdev.community.apache.org%3E
> > >> >
> > >> > Hi,
> > >> >
> > >> > I agree that we can not force anyone to do anything in the project.
> > >> >
> > >> > But we can still discuss how we can clean up this issue faster.
> > >> >
> > >> > When I was reading the legacy issues recently, I've learned
> something
> > >> > that I would like to share.
> > >> >
> > >> > 1. Some of the issue are quite similar, these frequently asked
> > >> > question can be summarized to the FAQ, and I think the FAQ should be
> > >> > improved by anyone. That means the current FAQ should be put to
> > >> > somewhere other than Wiki.
> > >> > 2. Some of issues are not clearly described, making us hard to
> > >> > reproduce, or reported long time ago. For these kind of issues, I
> > >> > think simply reply with "Thanks for your question, would you please
> > >> > try the latest version? I am going to close this issue now. Feel
> free
> > >> > to reopen it if the problem still exists." and close it will be
> fine.
> > >> > 3. Triage the issue with labels. This make not even committers but
> > >> > contributors easily to find. For example, a label of "good start
> > >> > issue" or "help wanted" may attract new users to easily jump in and
> > >> > help. I've also added to "How can I contribute" in README.
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >>
> > >> >> Mark
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Best Regards!
> > >> > Huxing
> > >>
> > >>
> > >>
> > >> --
> > >> Best Regards!
> > >> Huxing
> > >>
> > >
> > >
> >
>

Re: [Discuss]Suggestion for solve issues more quickly and effectively

Posted by Yong Zhu <di...@gmail.com>.
How about 'NEED-CLOSE' ?

On Wed, Jul 18, 2018 at 6:38 PM yuhang xiu <ca...@gmail.com> wrote:

> I agree.
> But, is '&READY-TO-CLOSE&' too long to use ?  How about a abbreviation like
> &RTC& or sth?
>
> (Sorry about last mail..)
>
> 2018-07-18 18:37 GMT+08:00 yuhang xiu <ca...@gmail.com>:
>
> > I agree.
> > But, is '&READY-TO-CLOSE&' too long to use ?  How about a abbreviation
> > like &RTC& or
> >
> > 2018-07-18 18:22 GMT+08:00 Huxing Zhang <hu...@apache.org>:
> >
> >> Hi,
> >>
> >> I just have a new idea!
> >>
> >> For an issue that is ready to be closed, anyone can comment with
> >> special characters, say, &READY-TO-CLOSE&.
> >>
> >> So committers can search the issue with the special characters, and
> >> deal with it.
> >>
> >> https://github.com/apache/incubator-dubbo/issues?utf8=%E2%
> >> 9C%93&q=is%3Aissue+is%3Aopen+%26READY-TO-CLOSE%26
> >>
> >> In this way, we can encourage users to check the existing issues and
> mark
> >> them.
> >>
> >> How do you think?
> >>
> >> On Tue, Jul 17, 2018 at 1:56 PM, Huxing Zhang <hu...@apache.org>
> wrote:
> >> > On Tue, Jul 10, 2018 at 11:39 PM, Mark Thomas <ma...@apache.org>
> wrote:
> >> >> On 10/07/18 07:04, jun liu wrote:
> >> >>> Hi All,
> >> >>>
> >> >>> Now the community has become very active, pull requests and issues
> >> are being reported in a certain amount every day, in contrast, our
> response
> >> seems not fast enough and issues bumped up.
> >> >>>
> >> >>> I've thought of a duty table for temporarily solving this problem,
> >> committers on duty are responsible for responding to community
> activities,
> >> classify issues and resolve/assign issues, by doing that, we can
> guarantee
> >> at least some of the committers devote enough time to the community
> every
> >> day.
> >> >>>
> >> >>> Remember that we still need to encourage users to participate in any
> >> kind of contribution, and anyone can still participate in the community
> at
> >> any time.
> >> >>>
> >> >>> Here’s an example duty form: https://github.com/apache/incu
> >> bator-dubbo/wiki/Duty-Form
> >> >>> Remember label issues: https://github.com/apache/incu
> >> bator-dubbo/wiki/Label-an-Issue
> >> >>>
> >> >>> Do you guys have any ideas of how to achieve this goal?
> >> >>
> >> >> Just remember that every committer is a volunteer and that they get
> to
> >> >> choose what they work on. Allocating committers to tasks isn't
> >> something
> >> >> that happens on an ASF project.
> >> >>
> >> >> Growing the community is the obvious answer to an increasing backlog
> of
> >> >> issues. If you haven't already seen it I strongly recommend reading
> >> this
> >> >> post that talks about Apache Beam's experience in this area:
> >> >>
> >> >> https://lists.apache.org/thread.html/33a6c3aa0fffa6e961aa2b8
> >> 61ebde333d898a5e1062d0d71d0e13d46@%3Cdev.community.apache.org%3E
> >> >
> >> > Hi,
> >> >
> >> > I agree that we can not force anyone to do anything in the project.
> >> >
> >> > But we can still discuss how we can clean up this issue faster.
> >> >
> >> > When I was reading the legacy issues recently, I've learned something
> >> > that I would like to share.
> >> >
> >> > 1. Some of the issue are quite similar, these frequently asked
> >> > question can be summarized to the FAQ, and I think the FAQ should be
> >> > improved by anyone. That means the current FAQ should be put to
> >> > somewhere other than Wiki.
> >> > 2. Some of issues are not clearly described, making us hard to
> >> > reproduce, or reported long time ago. For these kind of issues, I
> >> > think simply reply with "Thanks for your question, would you please
> >> > try the latest version? I am going to close this issue now. Feel free
> >> > to reopen it if the problem still exists." and close it will be fine.
> >> > 3. Triage the issue with labels. This make not even committers but
> >> > contributors easily to find. For example, a label of "good start
> >> > issue" or "help wanted" may attract new users to easily jump in and
> >> > help. I've also added to "How can I contribute" in README.
> >> >
> >> >
> >> >
> >> >
> >> >>
> >> >> Mark
> >> >
> >> >
> >> >
> >> > --
> >> > Best Regards!
> >> > Huxing
> >>
> >>
> >>
> >> --
> >> Best Regards!
> >> Huxing
> >>
> >
> >
>

Re: [Discuss]Suggestion for solve issues more quickly and effectively

Posted by yuhang xiu <ca...@gmail.com>.
I agree.
But, is '&READY-TO-CLOSE&' too long to use ?  How about a abbreviation like
&RTC& or sth?

(Sorry about last mail..)

2018-07-18 18:37 GMT+08:00 yuhang xiu <ca...@gmail.com>:

> I agree.
> But, is '&READY-TO-CLOSE&' too long to use ?  How about a abbreviation
> like &RTC& or
>
> 2018-07-18 18:22 GMT+08:00 Huxing Zhang <hu...@apache.org>:
>
>> Hi,
>>
>> I just have a new idea!
>>
>> For an issue that is ready to be closed, anyone can comment with
>> special characters, say, &READY-TO-CLOSE&.
>>
>> So committers can search the issue with the special characters, and
>> deal with it.
>>
>> https://github.com/apache/incubator-dubbo/issues?utf8=%E2%
>> 9C%93&q=is%3Aissue+is%3Aopen+%26READY-TO-CLOSE%26
>>
>> In this way, we can encourage users to check the existing issues and mark
>> them.
>>
>> How do you think?
>>
>> On Tue, Jul 17, 2018 at 1:56 PM, Huxing Zhang <hu...@apache.org> wrote:
>> > On Tue, Jul 10, 2018 at 11:39 PM, Mark Thomas <ma...@apache.org> wrote:
>> >> On 10/07/18 07:04, jun liu wrote:
>> >>> Hi All,
>> >>>
>> >>> Now the community has become very active, pull requests and issues
>> are being reported in a certain amount every day, in contrast, our response
>> seems not fast enough and issues bumped up.
>> >>>
>> >>> I've thought of a duty table for temporarily solving this problem,
>> committers on duty are responsible for responding to community activities,
>> classify issues and resolve/assign issues, by doing that, we can guarantee
>> at least some of the committers devote enough time to the community every
>> day.
>> >>>
>> >>> Remember that we still need to encourage users to participate in any
>> kind of contribution, and anyone can still participate in the community at
>> any time.
>> >>>
>> >>> Here’s an example duty form: https://github.com/apache/incu
>> bator-dubbo/wiki/Duty-Form
>> >>> Remember label issues: https://github.com/apache/incu
>> bator-dubbo/wiki/Label-an-Issue
>> >>>
>> >>> Do you guys have any ideas of how to achieve this goal?
>> >>
>> >> Just remember that every committer is a volunteer and that they get to
>> >> choose what they work on. Allocating committers to tasks isn't
>> something
>> >> that happens on an ASF project.
>> >>
>> >> Growing the community is the obvious answer to an increasing backlog of
>> >> issues. If you haven't already seen it I strongly recommend reading
>> this
>> >> post that talks about Apache Beam's experience in this area:
>> >>
>> >> https://lists.apache.org/thread.html/33a6c3aa0fffa6e961aa2b8
>> 61ebde333d898a5e1062d0d71d0e13d46@%3Cdev.community.apache.org%3E
>> >
>> > Hi,
>> >
>> > I agree that we can not force anyone to do anything in the project.
>> >
>> > But we can still discuss how we can clean up this issue faster.
>> >
>> > When I was reading the legacy issues recently, I've learned something
>> > that I would like to share.
>> >
>> > 1. Some of the issue are quite similar, these frequently asked
>> > question can be summarized to the FAQ, and I think the FAQ should be
>> > improved by anyone. That means the current FAQ should be put to
>> > somewhere other than Wiki.
>> > 2. Some of issues are not clearly described, making us hard to
>> > reproduce, or reported long time ago. For these kind of issues, I
>> > think simply reply with "Thanks for your question, would you please
>> > try the latest version? I am going to close this issue now. Feel free
>> > to reopen it if the problem still exists." and close it will be fine.
>> > 3. Triage the issue with labels. This make not even committers but
>> > contributors easily to find. For example, a label of "good start
>> > issue" or "help wanted" may attract new users to easily jump in and
>> > help. I've also added to "How can I contribute" in README.
>> >
>> >
>> >
>> >
>> >>
>> >> Mark
>> >
>> >
>> >
>> > --
>> > Best Regards!
>> > Huxing
>>
>>
>>
>> --
>> Best Regards!
>> Huxing
>>
>
>

Re: [Discuss]Suggestion for solve issues more quickly and effectively

Posted by yuhang xiu <ca...@gmail.com>.
I agree.
But, is '&READY-TO-CLOSE&' too long to use ?  How about a abbreviation like
&RTC& or

2018-07-18 18:22 GMT+08:00 Huxing Zhang <hu...@apache.org>:

> Hi,
>
> I just have a new idea!
>
> For an issue that is ready to be closed, anyone can comment with
> special characters, say, &READY-TO-CLOSE&.
>
> So committers can search the issue with the special characters, and
> deal with it.
>
> https://github.com/apache/incubator-dubbo/issues?utf8=%
> E2%9C%93&q=is%3Aissue+is%3Aopen+%26READY-TO-CLOSE%26
>
> In this way, we can encourage users to check the existing issues and mark
> them.
>
> How do you think?
>
> On Tue, Jul 17, 2018 at 1:56 PM, Huxing Zhang <hu...@apache.org> wrote:
> > On Tue, Jul 10, 2018 at 11:39 PM, Mark Thomas <ma...@apache.org> wrote:
> >> On 10/07/18 07:04, jun liu wrote:
> >>> Hi All,
> >>>
> >>> Now the community has become very active, pull requests and issues are
> being reported in a certain amount every day, in contrast, our response
> seems not fast enough and issues bumped up.
> >>>
> >>> I've thought of a duty table for temporarily solving this problem,
> committers on duty are responsible for responding to community activities,
> classify issues and resolve/assign issues, by doing that, we can guarantee
> at least some of the committers devote enough time to the community every
> day.
> >>>
> >>> Remember that we still need to encourage users to participate in any
> kind of contribution, and anyone can still participate in the community at
> any time.
> >>>
> >>> Here’s an example duty form: https://github.com/apache/
> incubator-dubbo/wiki/Duty-Form
> >>> Remember label issues: https://github.com/apache/
> incubator-dubbo/wiki/Label-an-Issue
> >>>
> >>> Do you guys have any ideas of how to achieve this goal?
> >>
> >> Just remember that every committer is a volunteer and that they get to
> >> choose what they work on. Allocating committers to tasks isn't something
> >> that happens on an ASF project.
> >>
> >> Growing the community is the obvious answer to an increasing backlog of
> >> issues. If you haven't already seen it I strongly recommend reading this
> >> post that talks about Apache Beam's experience in this area:
> >>
> >> https://lists.apache.org/thread.html/33a6c3aa0fffa6e961aa2b861ebde3
> 33d898a5e1062d0d71d0e13d46@%3Cdev.community.apache.org%3E
> >
> > Hi,
> >
> > I agree that we can not force anyone to do anything in the project.
> >
> > But we can still discuss how we can clean up this issue faster.
> >
> > When I was reading the legacy issues recently, I've learned something
> > that I would like to share.
> >
> > 1. Some of the issue are quite similar, these frequently asked
> > question can be summarized to the FAQ, and I think the FAQ should be
> > improved by anyone. That means the current FAQ should be put to
> > somewhere other than Wiki.
> > 2. Some of issues are not clearly described, making us hard to
> > reproduce, or reported long time ago. For these kind of issues, I
> > think simply reply with "Thanks for your question, would you please
> > try the latest version? I am going to close this issue now. Feel free
> > to reopen it if the problem still exists." and close it will be fine.
> > 3. Triage the issue with labels. This make not even committers but
> > contributors easily to find. For example, a label of "good start
> > issue" or "help wanted" may attract new users to easily jump in and
> > help. I've also added to "How can I contribute" in README.
> >
> >
> >
> >
> >>
> >> Mark
> >
> >
> >
> > --
> > Best Regards!
> > Huxing
>
>
>
> --
> Best Regards!
> Huxing
>

Re: [Discuss]Suggestion for solve issues more quickly and effectively

Posted by Huxing Zhang <hu...@apache.org>.
Hi,

I just have a new idea!

For an issue that is ready to be closed, anyone can comment with
special characters, say, &READY-TO-CLOSE&.

So committers can search the issue with the special characters, and
deal with it.

https://github.com/apache/incubator-dubbo/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+%26READY-TO-CLOSE%26

In this way, we can encourage users to check the existing issues and mark them.

How do you think?

On Tue, Jul 17, 2018 at 1:56 PM, Huxing Zhang <hu...@apache.org> wrote:
> On Tue, Jul 10, 2018 at 11:39 PM, Mark Thomas <ma...@apache.org> wrote:
>> On 10/07/18 07:04, jun liu wrote:
>>> Hi All,
>>>
>>> Now the community has become very active, pull requests and issues are being reported in a certain amount every day, in contrast, our response seems not fast enough and issues bumped up.
>>>
>>> I've thought of a duty table for temporarily solving this problem, committers on duty are responsible for responding to community activities, classify issues and resolve/assign issues, by doing that, we can guarantee at least some of the committers devote enough time to the community every day.
>>>
>>> Remember that we still need to encourage users to participate in any kind of contribution, and anyone can still participate in the community at any time.
>>>
>>> Here’s an example duty form: https://github.com/apache/incubator-dubbo/wiki/Duty-Form
>>> Remember label issues: https://github.com/apache/incubator-dubbo/wiki/Label-an-Issue
>>>
>>> Do you guys have any ideas of how to achieve this goal?
>>
>> Just remember that every committer is a volunteer and that they get to
>> choose what they work on. Allocating committers to tasks isn't something
>> that happens on an ASF project.
>>
>> Growing the community is the obvious answer to an increasing backlog of
>> issues. If you haven't already seen it I strongly recommend reading this
>> post that talks about Apache Beam's experience in this area:
>>
>> https://lists.apache.org/thread.html/33a6c3aa0fffa6e961aa2b861ebde333d898a5e1062d0d71d0e13d46@%3Cdev.community.apache.org%3E
>
> Hi,
>
> I agree that we can not force anyone to do anything in the project.
>
> But we can still discuss how we can clean up this issue faster.
>
> When I was reading the legacy issues recently, I've learned something
> that I would like to share.
>
> 1. Some of the issue are quite similar, these frequently asked
> question can be summarized to the FAQ, and I think the FAQ should be
> improved by anyone. That means the current FAQ should be put to
> somewhere other than Wiki.
> 2. Some of issues are not clearly described, making us hard to
> reproduce, or reported long time ago. For these kind of issues, I
> think simply reply with "Thanks for your question, would you please
> try the latest version? I am going to close this issue now. Feel free
> to reopen it if the problem still exists." and close it will be fine.
> 3. Triage the issue with labels. This make not even committers but
> contributors easily to find. For example, a label of "good start
> issue" or "help wanted" may attract new users to easily jump in and
> help. I've also added to "How can I contribute" in README.
>
>
>
>
>>
>> Mark
>
>
>
> --
> Best Regards!
> Huxing



-- 
Best Regards!
Huxing

Re: [Discuss]Suggestion for solve issues more quickly and effectively

Posted by Huxing Zhang <hu...@apache.org>.
On Tue, Jul 10, 2018 at 11:39 PM, Mark Thomas <ma...@apache.org> wrote:
> On 10/07/18 07:04, jun liu wrote:
>> Hi All,
>>
>> Now the community has become very active, pull requests and issues are being reported in a certain amount every day, in contrast, our response seems not fast enough and issues bumped up.
>>
>> I've thought of a duty table for temporarily solving this problem, committers on duty are responsible for responding to community activities, classify issues and resolve/assign issues, by doing that, we can guarantee at least some of the committers devote enough time to the community every day.
>>
>> Remember that we still need to encourage users to participate in any kind of contribution, and anyone can still participate in the community at any time.
>>
>> Here’s an example duty form: https://github.com/apache/incubator-dubbo/wiki/Duty-Form
>> Remember label issues: https://github.com/apache/incubator-dubbo/wiki/Label-an-Issue
>>
>> Do you guys have any ideas of how to achieve this goal?
>
> Just remember that every committer is a volunteer and that they get to
> choose what they work on. Allocating committers to tasks isn't something
> that happens on an ASF project.
>
> Growing the community is the obvious answer to an increasing backlog of
> issues. If you haven't already seen it I strongly recommend reading this
> post that talks about Apache Beam's experience in this area:
>
> https://lists.apache.org/thread.html/33a6c3aa0fffa6e961aa2b861ebde333d898a5e1062d0d71d0e13d46@%3Cdev.community.apache.org%3E

Hi,

I agree that we can not force anyone to do anything in the project.

But we can still discuss how we can clean up this issue faster.

When I was reading the legacy issues recently, I've learned something
that I would like to share.

1. Some of the issue are quite similar, these frequently asked
question can be summarized to the FAQ, and I think the FAQ should be
improved by anyone. That means the current FAQ should be put to
somewhere other than Wiki.
2. Some of issues are not clearly described, making us hard to
reproduce, or reported long time ago. For these kind of issues, I
think simply reply with "Thanks for your question, would you please
try the latest version? I am going to close this issue now. Feel free
to reopen it if the problem still exists." and close it will be fine.
3. Triage the issue with labels. This make not even committers but
contributors easily to find. For example, a label of "good start
issue" or "help wanted" may attract new users to easily jump in and
help. I've also added to "How can I contribute" in README.




>
> Mark



-- 
Best Regards!
Huxing

Re: [Discuss]Suggestion for solve issues more quickly and effectively

Posted by Mark Thomas <ma...@apache.org>.
On 10/07/18 07:04, jun liu wrote:
> Hi All, 
> 
> Now the community has become very active, pull requests and issues are being reported in a certain amount every day, in contrast, our response seems not fast enough and issues bumped up. 
> 
> I've thought of a duty table for temporarily solving this problem, committers on duty are responsible for responding to community activities, classify issues and resolve/assign issues, by doing that, we can guarantee at least some of the committers devote enough time to the community every day. 
> 
> Remember that we still need to encourage users to participate in any kind of contribution, and anyone can still participate in the community at any time.
> 
> Here’s an example duty form: https://github.com/apache/incubator-dubbo/wiki/Duty-Form
> Remember label issues: https://github.com/apache/incubator-dubbo/wiki/Label-an-Issue
> 
> Do you guys have any ideas of how to achieve this goal?

Just remember that every committer is a volunteer and that they get to
choose what they work on. Allocating committers to tasks isn't something
that happens on an ASF project.

Growing the community is the obvious answer to an increasing backlog of
issues. If you haven't already seen it I strongly recommend reading this
post that talks about Apache Beam's experience in this area:

https://lists.apache.org/thread.html/33a6c3aa0fffa6e961aa2b861ebde333d898a5e1062d0d71d0e13d46@%3Cdev.community.apache.org%3E

Mark

Re: [Discuss]Suggestion for solve issues more quickly and effectively

Posted by Ian Luo <ia...@gmail.com>.
Let's triage issues daily, and tag the issues with 'good first issue' or
'help wanted'. It is committer's duty so let's put more focus on it.

Thanks,
-Ian.

On Tue, Jul 10, 2018 at 2:04 PM jun liu <ke...@gmail.com> wrote:

> Hi All,
>
> Now the community has become very active, pull requests and issues are
> being reported in a certain amount every day, in contrast, our response
> seems not fast enough and issues bumped up.
>
> I've thought of a duty table for temporarily solving this problem,
> committers on duty are responsible for responding to community activities,
> classify issues and resolve/assign issues, by doing that, we can guarantee
> at least some of the committers devote enough time to the community every
> day.
>
> Remember that we still need to encourage users to participate in any kind
> of contribution, and anyone can still participate in the community at any
> time.
>
> Here’s an example duty form:
> https://github.com/apache/incubator-dubbo/wiki/Duty-Form
> Remember label issues:
> https://github.com/apache/incubator-dubbo/wiki/Label-an-Issue
>
> Do you guys have any ideas of how to achieve this goal?
>
> Best regards,
> Jun