Bugzilla:Meetings:2013-07-17

Back to meetings list.

• Video recording of the meeting
• IRC logs for the meeting room

Minutes:

1. Project leadership structure changes (justdave)
   • LpSolit has stepped down from his Assistant Project Leader role; mkanat had already stepped down previously (officially 8 months ago, but in function around 2 years ago) and we never replaced him; This leaves justdave currently as the only "approver". Ideally we should have at least three, because everyone has "real lives" outside of Bugzilla development.
   • Some interest from (f1sh from Novell) in UX design.
   • Simon granted approver status.
2. Bugzilla.org website redesign (bug 891260) (justdave)
   • General agreement that it would be nice. IT supports WordPress. No one volunteering yet.
3. Documentation editing/structure changes (Gerv)
   • Current system requires too many dependencies, relies on antiquated XML.
   • Suggest converting to MarkDown or ReST to encourage contributions.
   • General acceptance of new doc format provided locally modified versions can be hosted easily.
4. Future Direction
   • Mozilla interested in performance improvements; would probably provide significant benefit only to other high-traffic installations.
   • Discussion on deprecating all APIs other than REST in a future version, perhaps 6.0. Would allow a cleaner, more intuitively RESTish design. Opposition that this would remove APIs listed as stable; counter that "stable" does not mean supported forever.
   • Clarified that it is acceptable for new features in version 5.0 to require JavaScript.
   • Interest from Novell in maintaining Testopia.
   • Majority in favour of moving Bugzilla source from bzr to git. Mixed opinions on hosting at git.mozilla.org versus github.com, but general agreement to mirror to github.com if hosted at git.mozilla.org.
   • Noted that Bugzilla does grouping-by-AND (if a bug belongs to multiple groups, you must belong to all groups to see the bug), and that this is very confusing to new users. Red Hat implemented an option to do grouping-by-OR (and submitted upstream patch, bug 452525), in which you need only belong to one of the groups to see the bug. Mozilla has 2500 bugs that belong to multiple groups; it's not clear if there's redundancy or if they really use the grouping-by-AND functionality consciously. Some objection to having it as an option as it would be further configuration complexity; retort that some existing sites can't easily switch.
5. Community Engagement
   • Need to reach out to maintainers of other big installations, e.g. Yahoo.
   • Contributing code changes is hard. There is currently an expectation to clean up related areas of code before a patch is accepted. This can discourage contributions, particularly from first-timers.
     • It was suggested to be more lenient in accepting new features that don't have a completely clean design or implementation and just file a bug for future cleanup/refactoring.
     • Noted that this has been tried before and left messy code.
     • Upstreaming documentation changes, however, could be made more lenient, possibly even without requiring review. This is how wikis function, like MDN: with post-commit reviews, facilitated by page watching.
   • Agreement that meetings should be monthly. Need to investigate Vidyo + Air Mozilla to determine if this would get around the Hangout 10-connection limit.