search

gratipay / inside.gratipay.com

Here lieth a pioneer in open source sustainability. RIP
https://gratipay.news/the-end-cbfba8f50981
58 stars 38 forks source link

one-page issue index #970

Closed nobodxbodon closed 6 years ago

nobodxbodon commented 7 years ago

Here's an ongoing attempt to index all the issues in one place. Maybe this is better to be in wiki, but I don't seem to have access. Please advise better forms and means, and welcome to edit.

nobodxbodon commented 7 years ago

Hopefully all the open issues till 01/08/2017 are covered. Working on the closed issues next.

chadwhitacre commented 7 years ago

Holy moly, @nobodxbodon. This is amazing! How about using Labels?

chadwhitacre commented 7 years ago

Working on the closed issues next.

How about looking at the gratipay.com repo next?

chadwhitacre commented 7 years ago

Because classifying our open issues seems more valuable than our closed ones.

nobodxbodon commented 7 years ago

@whit537 I try to use the same labels (governance, events, etc) when applicable, and please feel free to change if you find any of the categories not proper.

OK I'll start on gratipay.com issues next. Any suggestion on how to categorize?

chadwhitacre commented 7 years ago

This is wierd but I like it. I like having a comprehensive view of all of our issues. Could we make an appendix for Inside Gratipay that does this automatically based on labels?

nobodxbodon commented 7 years ago

Right I was thinking about using label mechanism to auto generate tree as well, but realized it wasn't a 1-hr project, plus I wanted to go over all the issues myself anyways.

There'll definitely be more motivation when I'm overwhelmed by maintaining the page (currently with <5 new issues per day I'm still fine). Also, we may adjust the categories before using them as labels.

nobodxbodon commented 7 years ago

Speaking of indexing the issues in gratipay.com, how about closing those issues that are high-level discussions rather than actionable items (bug, quick improvements, feature with concrete design), and open new issue or merge with similar issues in inside.gratipay.com? This way, gratipay.com issues can be more in control, and the audiences who are more willing to involve in discussions without technical details can have one single place (here) to meet.

Besides, is there any explanation about the labels used in gratipay.com issues? Like TeamX and TeamX*, etc.

mattbk commented 7 years ago

http://inside.gratipay.com/howto/label-github-issues?

nobodxbodon commented 7 years ago

how about closing those issues that are high-level discussions rather than actionable items (bug, quick improvements, feature with concrete design), and open new issue or merge with similar issues in inside.gratipay.com?

As example, I closed https://github.com/gratipay/gratipay.com/issues/84 and opened https://github.com/gratipay/inside.gratipay.com/issues/973. Looks OK?

chadwhitacre commented 7 years ago

Looks okay to me. :)

nobodxbodon commented 7 years ago

FYI I created an assembly issue support more means of payin and payout to assemble a dozen related issues in gratipay.com.

Besides I'll move the issues that are not user-oriented to here as well, like deploy branches to heroku automatically

chadwhitacre commented 7 years ago

user-oriented

Why is that the criterion, rather than the scope of the issue (gratipay.com vs. Gratipay as an organization, or cross-repo product questions)?

nobodxbodon commented 7 years ago

IMHO it's the collaborators who are interested in non-user-oriented issues, as users should not be impacted by them directly. Plus I thought the "issues" section in the inside.gratipay.com repository are meant to keep all the issues for collaborators, which I suppose I was wrong about.

chadwhitacre commented 7 years ago

The user/collaborator distinction does not map to the gratipay.com and inside.gratipay.com issue trackers. In fact, commenting on any of our 30 repos is a step on the way from user to collaborator! 💃

nobodxbodon commented 7 years ago

I see your point, and I will +100 for more user feedback like the latest https://github.com/gratipay/gratipay.com/issues/4293, not to mention how much I like to see users become collaborators.

I hope to make user feedback like above to stand out, and to have higher priority than the non-user-oriented ones, which most likely are brought out by collaborators themselves. Those maybe 80% of the non-user-oriented issues just over-shadow the other 20%, which the collaborators and more importantly the potential contributors should have paid more attention to.

Seems to me, for potential contributors that see the issue list (like me before I join) at first sight, the issues that are 2-4 years old without updating in 1-2 years just seem like "we thought about it but that's it" or "we can't fix the blockers for those somehow". IMO it's discouraging contribution than encouraging, and for many of those issues it may be better to reference by category on a "TODO list" kind of page on the website, and/or linked by README of the repository, and then close them in tracker. The collaborators or whoever interested are still able to revisit them whenever they have time and reopen whenever decide to work on any, and potential contributors won't be scared off by them in the beginning.

chadwhitacre commented 7 years ago

I hope to make user feedback like above to stand out, and to have higher priority than the non-user-oriented ones, which most likely are brought out by collaborators themselves.

How about a label? :)

nobodxbodon commented 7 years ago

How about a label? :)

That can be helpful, if with proper document and obvious link on README to easily access the list of issues with this label. Currently the labels are kind of mixed (star, "Team_", "ready to start", etc) and can be confusing.

chadwhitacre commented 7 years ago

I agree that our labeling is due for an overhaul. We should also fold together these three pages:

http://inside.gratipay.com/howto/label-github-issues http://inside.gratipay.com/howto/develop-software http://inside.gratipay.com/howto/use-github

nobodxbodon commented 7 years ago

About labeling, it may be clearer to add different aspects (area/status/type, etc), like https://github.com/google/dagger/issues. Maybe 'priority' as well?

Something like:

area: design/UI/data/documentation status: discuss/blocked/ready to start type: bug/enhancement/new feature priority: critical/major/normal/minor (same as https://www.drupal.org/core/issue-priority)

Still, maintaining labels are quite some work, as priority of issues can change over time.

chadwhitacre commented 7 years ago

I think we should handle prioritization via project boards, not labels. Our new work taxonomy is:

Other than that I think a hierarchy for labels would be great. Cloud Custodian provides another example of this pattern. Seems like the outline in the description on this ticket is a good starting point, ya?