On Mon, Jul 23, 2018 at 4:57 PM, yuhang xiu <[email protected]> wrote: > Agree ‘&READY-TO-CLOSE&’. > Constantly try the best solution. > :)
+1 > > 2018-07-23 16:52 GMT+08:00 Yong Zhu <[email protected]>: > >> On Fri, Jul 20, 2018 at 4:01 PM Huxing Zhang <[email protected]> wrote: >> >> > Hi, >> > >> > On Thu, Jul 19, 2018 at 6:11 PM, yuhang xiu <[email protected]> wrote: >> > > I think it is better. >> > > :) >> > > >> > > 2018-07-19 11:04 GMT+08:00 Yong Zhu <[email protected]>: >> > > >> > >> 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 <[email protected]> >> 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 <[email protected]>: >> > >> > >> > >> > > 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 <[email protected]>: >> > >> > > >> > >> > >> 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 <[email protected] >> > >> > >> > wrote: >> > >> > >> > On Tue, Jul 10, 2018 at 11:39 PM, Mark Thomas < >> [email protected]> >> > >> > 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
