search

CCI-MOC / hil

Hardware Isolation Layer, formerly Hardware as a Service
Apache License 2.0
24 stars 54 forks source link

"Github Issues" issues #952

Closed xuhang57 closed 6 years ago

xuhang57 commented 6 years ago
  1. Lots of issues are many years old and have no discussion at all.
  2. Lots of issues have no actionable items on the issue so that developers can easily figure out what functions/docs needed to be implemented
  3. Lots of issues are well discussed and waiting for developers to resolve.

In order to resolve these issues, can we discuss on how to organize it and what the policies are to open/close an issue?

Personally,

  1. For issues that opened a year ago (before 2017), if no one has discussed on that, we should close that. Or we should do a quick look at the HIL meeting and close them.

  2. For issues that have been discussed but no actionable items, we assign the actionable tasks needed label (or whatever name of the label) and urge the issuer to come up with a to-do list. Or at least have some actionable solutions. If the issuer cannot deliver, core developers should help on that.

  3. For issues that are waiting for developers to resolve, we assign the "waiting on contributors" label and having a section in the CONTRIBUTING that points to the list of issues with the label.

Another suggestion here is to schedule a time to clean up the issues under a certain guideline/plan. Having more than 100 issues on the project list doesn't look nice IMHO so it worths the effort.

One thing we could do is to do that during the HIL weekly meeting or find a time that works for everyone.

Thoughts/ideas are more than welcome!

naved001 commented 6 years ago

I am pretty sure at least 10-15 issues will be closed once the obmd stuff lands.

zenhack commented 6 years ago

I'm against closing anything that isn't clearly solved without discussion; unless it's blatantly fixed, we should at least briefly say "is this still relevant?" and decide what to do.

I think some version of:

for developer in $developers; do
    $developer commits to triaging $n issues per week
    other developers commit to responding to comments on issues.
done

should set us on a path to reducing the number of open issues.

xuhang57 commented 6 years ago

Totally agree. Currently, we are missing "$developer commits to triaging $n issues per week" and many of the issuers are no longer working/contributing to HIL. What I am purposing is to classify different types of issues and start triaging.

zenhack commented 6 years ago

We could just make a "needs triage" label, apply it to everything, and then start picking through and removing it as we assign things to people, decide to close them, etc.

Quoting Lucas H. Xu (2018-02-07 20:39:50)

Totally agree. Currently, we are missing "$developer commits to triaging $n issues per week" and many of the issuers are no longer working/contributing to HIL. What I am purposing is to classify different types of issues and start triaging.

naved001 commented 6 years ago

Can we close this meta issue now? We have identified and put labels on pretty much all the issues.

zenhack commented 6 years ago

I'm fine closing this. It doesn't seem to be providing much utility at this point anyway.