Entry tags:
Github Issues: now on the wiki!
I've synthesised discussions about and practical use of GHI into a single wiki page. Please shout if you want anything added or changed!
I've also gone through and replaced as many references to Bugzilla with references to GHI as (1) makes sense and (2) I am immediately able. There's about 20 pages still on my hit-list, not all of which I have the knowledge to deal with - if you feel like pitching in, please take one and let me know when it's done (or, if you don't have wiki access, let me know what the appropriate edits would be).
Pages outstanding:
I've also gone through and replaced as many references to Bugzilla with references to GHI as (1) makes sense and (2) I am immediately able. There's about 20 pages still on my hit-list, not all of which I have the knowledge to deal with - if you feel like pitching in, please take one and let me know when it's done (or, if you don't have wiki access, let me know what the appropriate edits would be).
Pages outstanding:
- Cap & Flag Documentation needs text of the referenced bug incorporated usefully.
- Directory structure#cgi-bin needs a referenced bug incorporated usefully.
- How To Do A Code Tour needs updating to reflect post-Bugzilla workflow and tools.
Picking a random bug needs updating to reflect post-Bugzilla workflow and tools, or to be deleted. Fey still needs to delete this properly, but hey- Stats Design needs text of the referenced bug incorporated usefully.
- Sending non-ESN e-mail to a user needs text of the referenced bug incorporated usefully.
- Using Qunit for testing JS needs text of a referenced bug incorporated usefully.
- Workers needs text of referenced bugs incorporated usefully.
- Community Wishlist, Commenting Wishlist and Userpic Wishlist: do we want to refile the dead bugs as issues?
- Design and Spec Template both assume a Bugzilla workflow and need to be updated to reflect new workflow and tools.
- Project Teams needs updating to reflect new workflow and tools.
- Accessibility: it is currently non-trivial to find accessibility-related bugs. In Bugzilla we had "why-accessibility". References to Bugzilla need removing; we need to discuss whether a label serving a similar function in GHI might be useful.
- Public-facing Pages Worksheet needs bug texts incorporated
no subject
Instinctive answer: Yes, and probably most of the other "why-$foo" labels would also be useful. I don't know if keeping that naming system would be correct, although that was certainly something that made sense about the Bugzilla setup, at least from my maybe-baby!dev standpoint.
no subject
no subject
no subject
(In the interests of documenting everything properly: I also flagged up two support-specific pages needing editing in #dreamwidth-support.)
no subject
no subject
no subject
no subject
no subject
no subject
no subject
ETA: removed link
no subject
no subject
no subject
no subject
no subject
I wouldn't be opposed, but I'd be against filing them just because they were filed before. That is, if they're going to be filed, we should revisit whether they're what we want to be doing at this point in time, etc.
no subject
...I'm not sure, possibly worth pinging Denise for.
no subject
We've kind of informally drifted away from this structure, at least as far as having specific bugs. maybe time to revisit the overall team stuff?
no subject
no subject
no subject
no subject
no subject