Re: Project Management Proposal!

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> 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.
>       - Complete customization of the issue types and what types can be
>       in each project.
>       - Components of a project for separating issues for easy sorting.
>       - Team management built in.
>       - Milestones
>       - An API for writing and reading data in the DB.
>       - Voting system (for issues, not comments on issues as far as I can
>       tell.)
>       - 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.)---
> *
>