Difference between revisions of "Dev Tools Discussion"
(→Issue Trackers: added preliminary notes on GHI, Bugzilla) |
(→Communities) |
||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 4: | Line 4: | ||
===Communities=== | ===Communities=== | ||
| + | Issues: | ||
| + | * Not the best for real-time | ||
| + | * Defaults to public | ||
| + | |||
| + | Good bits: | ||
| + | * Instant archival, no waiting | ||
| + | * Good for asynchronous communication | ||
| + | * Can be used to post members-locked | ||
| + | * Searchable by default | ||
===IRC=== | ===IRC=== | ||
| + | Issues: | ||
| + | * Mibbit doesn't work on Freenode. | ||
| + | * Freenode's webchat is not the best thing in the world. | ||
| + | * (Since policy is to not publicly log) Archiving the important bits takes effort. | ||
| + | |||
| + | Good bits: | ||
| + | * Can use a variety of clients to connect. | ||
| + | * Members are asked to not automatically create public logs; absence of by-default public logging helps contributors feel comfortable communicating unedited & making mistakes. | ||
==Issue Trackers== | ==Issue Trackers== | ||
===Bugzilla=== | ===Bugzilla=== | ||
| − | Basic searches are | + | Basic searches of bug lists are very limited; advanced searches are non-intuitive to set up. |
| − | + | "Upload a patch" option is displayed by default on individual bug pages (is it possible to turn off?): we don't use this, but its presence can be worrying/offputting to new devs who don't yet know to ignore it. However, this functionality can be useful for attaching e.g. specifications, or screenshots of bugs that are difficult to describe in words. | |
| + | |||
| + | Having to create and immediately close a bug for one-line fixes that have already been written adds complexity for the sake of completeness. | ||
===Github Issues=== | ===Github Issues=== | ||
| Line 17: | Line 36: | ||
Issue tagging & assignment is only available to accounts with commit access to the repo. | Issue tagging & assignment is only available to accounts with commit access to the repo. | ||
| + | |||
| + | Devs have been conditioned to open bugs (in the Bugzilla model) before making a pull request. With the move to GHI, this is unnecessary and generates clutter. | ||
| + | |||
| + | A suitable workflow for managing security issues is unclear. | ||
==Github== | ==Github== | ||
Latest revision as of 15:56, 26 June 2014
Discussion at OSBridge 2014 led to the creation of this page, to make points of friction with our current tool set easier to track.
Contents
Communications
Communities
Issues:
- Not the best for real-time
- Defaults to public
Good bits:
- Instant archival, no waiting
- Good for asynchronous communication
- Can be used to post members-locked
- Searchable by default
IRC
Issues:
- Mibbit doesn't work on Freenode.
- Freenode's webchat is not the best thing in the world.
- (Since policy is to not publicly log) Archiving the important bits takes effort.
Good bits:
- Can use a variety of clients to connect.
- Members are asked to not automatically create public logs; absence of by-default public logging helps contributors feel comfortable communicating unedited & making mistakes.
Issue Trackers
Bugzilla
Basic searches of bug lists are very limited; advanced searches are non-intuitive to set up.
"Upload a patch" option is displayed by default on individual bug pages (is it possible to turn off?): we don't use this, but its presence can be worrying/offputting to new devs who don't yet know to ignore it. However, this functionality can be useful for attaching e.g. specifications, or screenshots of bugs that are difficult to describe in words.
Having to create and immediately close a bug for one-line fixes that have already been written adds complexity for the sake of completeness.
Github Issues
Search of GHI is non-obvious but extant (on issues page, the otherwise site-wide search box searches the issues).
Issue tagging & assignment is only available to accounts with commit access to the repo.
Devs have been conditioned to open bugs (in the Bugzilla model) before making a pull request. With the move to GHI, this is unnecessary and generates clutter.
A suitable workflow for managing security issues is unclear.
