Re: Project Management Proposal!

Hi, Garbee-

I don't agree with all of this, but I think it's a great effort to 
summarize several related issues, and I think you've made some excellent 
points.

Personally, I believe that the clearest, easiest, most productive, and 
least controversial step we can take is to install, configure, and 
document The Bug Genie for this project.

We can keep talking about other parts of your proposal, but I'd like to 
see us first tackle this one.

Let's set up a time for you and Ryan to start on getting this 
installation started.

Regards-
-Doug

On 1/3/13 8:57 PM, Julee Burdekin wrote:
> Great! I comments as well. Thanks, Garbee!! J
>
>
>         ----------------------------
>
>
>         julee@adobe.com
>
>
>         @adobejulee
>
>
> From: Alex Komoroske <komoroske@google.com <mailto:komoroske@google.com>>
> Date: Thursday, January 3, 2013 4:57 PM
> To: Jonathan Garbee <jonathan@garbee.me <mailto:jonathan@garbee.me>>
> Cc: "public-webplatform@w3.org <mailto:public-webplatform@w3.org>"
> <public-webplatform@w3.org <mailto:public-webplatform@w3.org>>
> Subject: Re: Project Management Proposal!
> Resent-From: <public-webplatform@w3.org <mailto:public-webplatform@w3.org>>
> Resent-Date: Thursday, January 3, 2013 4:58 PM
>
> Thank you so much for taking the time to come up with this. It's very
> comprehensive and I agree with most of it.
>
> I left a number of comments in the Google Doc.
>
> On Thu, Jan 3, 2013 at 2:33 PM, Jonathan Garbee <jonathan@garbee.me
> <mailto:jonathan@garbee.me>> wrote:
>
>     Yes, finally it is here. After a few major re-directions and
>     rewrites it is solid enough to propose. Honestly, most of it is
>     dealing directly with setup and configuration of a new issue
>     tracker. There are parts that go over the other methods we are using
>     to track things (hopefully I hit them all, if one was missed please
>     let me know.) It is pretty long, and sorry no tl;dr version. :/ So,
>     let me know how much you hate me ASAP so we can fix it to make it
>     awesome.
>
>     Now, enjoy!
>
>     -Garbee
>
>     You can see it inline below or the Google Doc version here:
>     https://docs.google.com/document/d/1fhyplXiVGOH4096bsbJP68uGqzI6vpUJTqEzbXLgDCI/edit
>
>     --- The Proposal (just shy of 1500 words) ---
>
>     *Comment System
>
>     The comment system is currently not being utilized too much (if at
>     all now) to help us edit content. The main uses are:
>     A) reporting issues people have with the content
>     B) Complaining/reporting issues with the site itself versus the
>     content (Like the font color, bugs in the UI in areas like tables,
>     no syntax highlighting, etc.)
>
>     This system should be taken down once we have a system in place to
>     replace it. It is adding extra things for people to look at in order
>     to see what is going on. There is an open bug [
>     https://www.w3.org/Bugs/Public/show_bug.cgi?id=19847] which is a
>     request to keep the comment system since it can “provide more help
>     than the documentation” if it were used properly. This shouldn’t be
>     the use for the comment system with the setup we are trying to
>     establish. If we are to have documentation, then any good content
>     should end up in the documentation. No good content should be hidden
>     away in a secondary area.
>
>     Until we have a replacement system ready to go, we should improve
>     the system by adding a hook so comments will go into the Recent
>     Changes list.
>
>     The current main uses for the comment system are what the W3 bug
>     tracker is for. Speaking of that...
>
>     Issue Tracking
>     Tracking issues and edits in Bugzilla is ridiculous. The software
>     was built in the late 1990’s with an apparent aim to track issues
>     with desktop software. First off, we aren’t tracking desktop
>     software issues. So why use a system built for that use-case?
>     Second, there has been a lot of complaints about the tracker not
>     being in-house. Let’s fix that.
>
>     Bringing the issue tracker in-house gives us options. We have
>     Bugzilla, Mantis, and The Bug Genie. (The latter one being
>     *seriously* mis-named for the amount of things it can handle.) These
>     are honestly the top three choices of software to manage the
>     project. In testing quite a few true “Project Management” solutions
>     it has revealed that none allow for public viewing of the issues,
>     much less reporting.
>
>     So covering the three main choices that fit this projects needs and
>     are open source.
>
>       * Bugzilla, we use now and hopefully never again. Right now we all
>         see how atrocious this thing is for what we are doing.
>       * Mantis, A perfectly valid choice if we want just a simple issue
>         tracker. It is basically Bugzilla but a nicer UI and much easier
>         to install. Also seems less annoying in some places.
>       * Finally, The Bug Genie. This software has tons of features that
>         we can use; most of which Bugzilla and Mantis don’t support.
>           o Complete customization of the issue types and what types can
>             be in each project.
>           o Components of a project for separating issues for easy sorting.
>           o Team management built in.
>           o Milestones
>           o An API for writing and reading data in the DB.
>           o Voting system (for issues, not comments on issues as far as
>             I can tell.)
>           o OpenID support so people can login with an existing account.
>
>
>     Assuming the Bug Genie is what we decide to move forward with, the
>     rest of this section aims to help explain how that would be configured.
>
>     Issues:
>     Each project can have its own issue report types with their own
>     fields for submission. Initially we would use the same three or four
>     across the entire system. Over time we would tune the projects for
>     simplicity. For example we wouldn’t have bug reports in the Content
>     project since the content really doesn’t have bugs.
>
>     We would assign the severity of the issue depending on how important
>     it is within its milestone.
>
>     Organization and teams:
>     The system would contain the same project that Bugzilla contains
>     now. These projects would then contain components as-needed to
>     specifically separate certain issues. For example Content would have
>     HTMl, CSS, JS, and A11y components.
>
>     Each project teams to group people together based on what content
>     they want to work on such as HTML, CSS, JS, and A11y for content.
>     Perhaps these can even be more granular to cover Tutorials,
>     Concepts, and Reference teams for each in case people are interested
>     in doing specific parts of the content. Along with these teams we
>     would create components in projects that it makes sense to, such as
>     Content. The components in this case would be the main categories to
>     start and made more granular as needed down the road. Also a team
>     would be needed specifically to cover delete flags.
>
>
>     Milestones (and roadmapping):
>     Milestones would be set according to points determined in the final
>     process of getting a roadmap to alpha drop. We need to decide
>     exactly what we want from a documentation site that qualifies it to
>     be released and then work our way from that goal back to figure out
>     everything that needs to be done within each part of the project.
>     Once overall goals are set then we will set milestones to group
>     things together. This will allow us to have specific goals to focus
>     on for a real goal, not just what needs to be done in a certain
>     point of time as we have been doing so far.
>
>     Feedback
>     A feedback form should be created.  Perhaps have it tie into the Bug
>     Genie's API so a new issue is created in a "Feedback" project when
>     something is submitted.  Or we could tie it into the mailing list
>     although that could end up creating lots of extra email for us.
>
>     Should we find some volunteers to be community relations who people
>     can email or get in touch with via social networks with their issues
>     and needs?  Feedback and getting it from editors/developers is
>     something we *really* need to work on together. I have few ideas
>     myself for doing it.
>
>     Frontend Integration
>     Integrating the system on the frontend will require a few things:
>
>      1. Submitting an issue for a section of an article.
>      2. Submitting feedback (good or bad) about the site in general.
>      3. Checking for if issues existing against a page’s content.
>      4. Having flags automatically create an issue for review.
>
>     We can discuss the exact UI to this system as work begins on it.
>     Eventually it will be what replaces the Comment System. Up front
>     though, the comment system stays so this will be something we throw
>     onto the Roadmap and figure out more specifics later.
>
>     Telcons and Mailing List
>     Should we keep really doing Telcons?  Clumsy and the same can be
>     achieved through a dedicated IRC time (adding a supybot with the
>     meetbot plugin for making clean notes almost automatically) or the
>     issue tracker with accurate logs and less miscommunication.
>     The Mailing List could also be consolidated into a “Discussion”
>     project of the issue tracker. Then we are eliminating yet another
>     place for discussion to be going on and keeping things in once place.
>     Just some ideas to think about with this section, of course we
>     shouldn’t go rushing into abandoning every way of talking.
>
>     Question to Answer
>     First, we need to get SSO (Single Sign On) working between this and
>     MediaWiki. SSO is what is causing the session issues, so that either
>     gets solved or this system is taken offline until we can figure out
>     what the problem is.
>
>     We also need to decide if it is worth keeping around overall. Right
>     now it is not used for anything productive. There are some random on
>     kindof on-topic things. Considering all the talk of the exact use of
>     the Q&A and Chatroom shortly after launch I’m pretty sure we are
>     still not wanting to open it up for just general support questions
>     since that would possibly add a lot of extra noise to sift through.
>     We should discuss what use the system has in the future of WPD if
>     any and take action from there.
>
>     If the Question to Answer system is going to stick around then a few
>     updates will be in order.
>
>       * Install the FAQ extension. This will allow us to have a FAQ just
>         for that software within its navigation for easy viewing. It
>         will explain what types of questions should be asked and other
>         main questions (such as the point system.)
>       * Categorizing. We will need to make categories for the questions
>         for better sorting. Simply relying on proper tagging isn’t
>         working since people often seem to overlook tagging (if they
>         even do it right.)
>
>
>       * Tagging Tools extension. This will help us keep tags that are
>         used somewhat regular.
>       * Possibly a polls extension. This would be something we would use
>         to help get feedback from the community in a bit more organized
>         way when trying to make decisions on things.
>
>
>     Main steps to get going.
>
>      1. Get The Bug Genie online and current reports imported. Overall
>         this should take about a week.
>      2. Roadmap to alpha drop.
>      3. Set milestones. Will be based on the roadmap that is created.
>      4. Work towards the first milestone.
>
>
>     ---End proposal (I hope no one took this as a marriage proposal.)---
>     *
>
>

Received on Friday, 4 January 2013 08:31:55 UTC