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/ > 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 >
