{"action":"created","issue":{"url":"https://api.github.com/repos/apache/couchdb/issues/499","repository_url":"https://api.github.com/repos/apache/couchdb","labels_url":"https://api.github.com/repos/apache/couchdb/issues/499/labels{/name}","comments_url":"https://api.github.com/repos/apache/couchdb/issues/499/comments","events_url":"https://api.github.com/repos/apache/couchdb/issues/499/events","html_url":"https://github.com/apache/couchdb/issues/499","id":225207338,"number":499,"title":"Sort out GitHub issues for gitbox repos","user":{"login":"wohali","id":112292,"avatar_url":"https://avatars1.githubusercontent.com/u/112292?v=3","gravatar_id":"","url":"https://api.github.com/users/wohali","html_url":"https://github.com/wohali","followers_url":"https://api.github.com/users/wohali/followers","following_url":"https://api.github.com/users/wohali/following{/other_user}","gists_url":"https://api.github.com/users/wohali/gists{/gist_id}","starred_url":"https://api.github.com/users/wohali/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wohali/subscriptions","organizations_url":"https://api.github.com/users/wohali/orgs","repos_url":"https://api.github.com/users/wohali/repos","events_url":"https://api.github.com/users/wohali/events{/privacy}","received_events_url":"https://api.github.com/users/wohali/received_events","type":"User","site_admin":false},"labels":[{"id":594290962,"url":"https://api.github.com/repos/apache/couchdb/labels/discussion","name":"discussion","color":"CC317C","default":false},{"id":594291013,"url":"https://api.github.com/repos/apache/couchdb/labels/rfc","name":"rfc","color":"CC317C","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2017-04-28T22:26:17Z","updated_at":"2017-05-05T22:33:36Z","closed_at":null,"body":"We've got 'em, we want to use 'em instead of JIRA. Everyone on the project is +1, we just need a system. Here's some proposed rules; I'm keeping them simple.\r\n\r\n# Assignees\r\nSelf-explanatory.\r\n* Assign yourself if you start working on an issue.\r\n* De-assign yourself if you abandon an issue or won't be able to address it promptly.\r\n* Don't assign an issue to someone else without their explicit approval.\r\n* To avoid [cookie-licking](http://communitymgt.wikia.com/wiki/Cookie_Licking), our PMC should consider periodically de-assigning idle issues. How idle is idle? 3 months seems a good timeline to me. Writing a script to do this that runs on a cronjob should be straightforward.\r\n\r\n# Tagging\r\nI particularly like what [Robin have done](https://robinpowered.com/blog/best-practice-system-for-organizing-and-tagging-github-issues/) with their colouring-and-categorizing system. So, inspired by that, here's the proposal. Remember an issue can (and probably should) have more than one tag.\r\n\r\n* Component: Various sub-components of Apache CouchDB. Can be expanded with `search`, `geo`, etc. in the future. (light blue)\r\n  * build (toolchain, CI, etc.)\r\n  * documentation (and/or below in Experience?)\r\n  * dbcore (CouchDB database core)\r\n  * fauxton\r\n  * http_api\r\n  * javascript\r\n  * mango\r\n  * nano (couchdb-nano client)\r\n  * packaging (.deb, .rpm, snap, etc.)\r\n  * plugins\r\n  * replication (debatable, but this comes up enough)\r\n  * testsuite\r\n  * viewserver (the API)\r\n* Problems (red) - Issues that make the product feel broken. High priority, especially if its present in production.\r\n  * bug\r\n  * security\r\n  * production\r\n* Mindless (beige) - Reorganizing folder structure, legal stuff, and other necessary (but less impactful) tasks.\r\n  * chore\r\n  * legal\r\n* Experience (orange) - Affect user’s comprehension, or overall enjoyment of the product. These can be both opportunities and “UX bugs”.\r\n  * UX (could include API debates or installation as well as Fauxton)\r\n  * documentation (and/or above in Components?)\r\n  * design (primarily for Fauxton)\r\n  * website (https://couchdb.apache.org/ and related websites)\r\n* Environment (pink)\r\n  * windows\r\n  * linux\r\n  * macos\r\n  * freebsd\r\n  * docker\r\n  * etc.\r\n* Feedback (magenta) - Requires further conversation to figure out the action steps. Most feature ideas start here.\r\n  * discussion\r\n  * rfc\r\n  * question\r\n* Improvements (blue) - Iterations on existing features or infrastructure. Generally these update speed, or improve the quality of results.\r\n  * enhancement\r\n  * optimization\r\n* Additions (green) - Brand new functionality.\r\n  * feature\r\n* Pending (yellow) - Taking action, but need a few things to happen first. A feature that needs dependencies merged, or a bug that needs further data.\r\n  * in progress\r\n  * watchlist\r\n  * waiting on user\r\n* Inactive (grey) - No action needed or possible. The issue is either fixed, addressed better by other issues, or just out of scope.\r\n  * invalid\r\n  * wontfix\r\n  * duplicate\r\n  * on hold\r\n\r\n# Projects\r\nNot useful for us right now.\r\n\r\n# Milestones\r\nWe should be using this for version targeting and mass-updating as necessarily. I.e., bugs get targeted for the next minor release, new features that break the API for the next major release, etc. Think v2.1.0, v3.0.0, etc. (Rathole: v or no v?)\r\n\r\n# Issue template\r\nGoing to start with [this one](https://github.com/TalAter/open-source-templates/blob/master/ISSUE_TEMPLATE.md).\r\n\r\n# PR template\r\nUpdate to change reference from JIRA to GH Issues. Remind people to include text like \"Fixes #472\" to link a PR to an issue.\r\n\r\n# Contributing\r\nWe've had requests for this before, should we add one?\r\n\r\n# Multi-repo\r\nWe still have a number of repos that aren't likely to be merged into apache/couchdb, like fauxton. I am suggesting we keep primary issue reporting here (in apache/couchdb) for all of our repos, and reference issues here from PRs in other repos (via apache/couchdb#472). We shouldn't disallow issues in other repos, but my guess is that they'll be limited to people 'in the know.'"},"comment":{"url":"https://api.github.com/repos/apache/couchdb/issues/comments/299590828","html_url":"https://github.com/apache/couchdb/issues/499#issuecomment-299590828","issue_url":"https://api.github.com/repos/apache/couchdb/issues/499","id":299590828,"user":{"login":"wohali","id":112292,"avatar_url":"https://avatars1.githubusercontent.com/u/112292?v=3","gravatar_id":"","url":"https://api.github.com/users/wohali","html_url":"https://github.com/wohali","followers_url":"https://api.github.com/users/wohali/followers","following_url":"https://api.github.com/users/wohali/following{/other_user}","gists_url":"https://api.github.com/users/wohali/gists{/gist_id}","starred_url":"https://api.github.com/users/wohali/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wohali/subscriptions","organizations_url":"https://api.github.com/users/wohali/orgs","repos_url":"https://api.github.com/users/wohali/repos","events_url":"https://api.github.com/users/wohali/events{/privacy}","received_events_url":"https://api.github.com/users/wohali/received_events","type":"User","site_admin":false},"created_at":"2017-05-05T22:33:36Z","updated_at":"2017-05-05T22:33:36Z","body":"The point of GitHub's milestones is to associate a milestone name, description, and optional due date with one or more issues. Milestones can also be open or closed. Typically I see milestones showing what work remains to get a release out the door - you get a nice little bargraph in the UI, for instance. But milestones could also be feature related.\r\n\r\nTags don't give you the bar graph or due date, and the tag space can get cluttered quickly (we already have 30 tags to choose from.) I'm nominally against using tags to coordinate releases as a result.\r\n\r\nIf we mirror what we've done in the past in JIRA, there are 2 scenarios where we've used the \"Fixed in release\" field that would match the GH Milestone function:\r\n\r\n1. To show we've fixed a reported bug and that it'll be patched in the next release\r\n2. To put a stake in the ground to say an issue is a release blocker\r\n\r\nIn that way I'm in favour of porting over exactly those 2 scenarios from JIRA \"Fixed in Release\" to GH Milestones."}}
{"actor":{"display_login":"wohali"}}