Skip to content
This repository has been archived by the owner on Nov 16, 2022. It is now read-only.

one-page issue index #970

Closed
nobodxbodon opened this issue Jan 8, 2017 · 21 comments
Closed

one-page issue index #970

nobodxbodon opened this issue Jan 8, 2017 · 21 comments
Assignees
@techtonik

Comments

@nobodxbodon
Copy link

nobodxbodon commented Jan 8, 2017 •
edited
Loading

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
Copy link
Author

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

@chadwhitacre
Copy link
Contributor

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

@chadwhitacre
Copy link
Contributor

Working on the closed issues next.

How about looking at the gratipay.com repo next?

@chadwhitacre
Copy link
Contributor

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

@nobodxbodon
Copy link
Author

@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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Author

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
Copy link
Contributor

mattbk commented Jan 11, 2017

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

@nobodxbodon
Copy link
Author

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 gratipay/gratipay.com#84 and opened #973. Looks OK?

@chadwhitacre
Copy link
Contributor

Looks okay to me. :)

@nobodxbodon
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

I see your point, and I will +100 for more user feedback like the latest gratipay/gratipay.com#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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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

  • Roadmap
    • Epic
      • Project
        • Issue/PR
          • Task

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?

This was referenced Jan 23, 2017
Closed
Closed
@techtonik techtonik self-assigned this Jan 2, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@techtonik techtonik

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@chadwhitacre @nobodxbodon @techtonik @mattbk