Project Management Proposal!

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.)---
*