W3C home > Mailing lists > Public > public-webplatform@w3.org > November 2012

Re: Telcon action: Task management proposal

From: Jonathan Garbee <jonathan@garbee.me>
Date: Mon, 05 Nov 2012 13:14:19 -0500
Message-ID: <509801FB.5080002@garbee.me>
To: public-webplatform@w3.org
Sorry, this email is long and I can't really tl;dr it.

The flag system I would *love* to keep around and eventually have it tie 
into automatically creating bug reports.  For now though it would simply 
stick around as a way for anyone to flag things and then editors as they 
are going through notice and work on.  Or if we could get (remember) a 
way to filter flags on the wiki I can just keep an eye on them and 
create reports until it gets automated.  The flags are *very* useful in 
the front-end to give immediate attention to the fact that there could 
be some issues with the document someone is looking at.

The comment system I would like to figure out how to do it as well (see 
bug 19847 [1] for a bit of info.)  But the comment system as it is now I 
don't see as a good idea to keep around from an administrative point of 
view.  It is a major UX drawback to have people go to another subdomain 
to simply file an issue to comment on a section of content.  So that 
*needs* to be solved, but using the current system would mean either 
doing some more work to it to make it easier to keep track of things and 
administrate them. Meanwhile it seems to me like we shouldn't really 
focus on updating that since the bugtracker can do it and we eventually 
have a plugin for it to act as comments.  This is just creating a UX 
issue for a while, but it would be worked out before dropping Alpha when 
it matters most.

Still going with comments, I also think that people see "comment" and 
think it can be just about anything.  We saw a lot of this at launch 
(especially on the main page which I cleaned all 30 something up) with 
people using it to ask why there was www1 vs www for the domain.  With 
other things along those lines which the comment system isn't meant for 
at all.  Perhaps just changing it from saying "comment" to "Discuss this 
content" would help make it clearer.  At that point though we still have 
administration of the comments to worry about.

It looks as if we can build an authentication module to let it use 
MediaWiki for authentication, therefore giving us SSO.  I think if we 
move that should be a critical component to get worked on. As far as 
thinking of what we would track:
* Everything the current tracker does.
* We can even track telcon items.  We have a section for things to be 
brought up in the Telcon, and as an action is created we can simply 
assign the report and move to the proper area of the tracker.  Bugzilla 
currently can do this, but it is over on W3 and can't interface with our 
* Content requests - Things people want to see added or edited. This 
would eventually be what comments would fall under probably.
* We could then track anything we could possibly think of.  It really 
comes down to creating the proper workflow if the default doesn't suite 
the need.  This tool is super powerful.

As far as the ease of having this bug creation automatic for flags and 
comments, I'm not too sure how that would work at the moment. I need to 
look through their documentation and see if they have some kind of 
system to facilitate that already or if it would need to be a custom job 

Editorial Notes on the other hand I am not sure of.  What is the real 
current use for these?  I haven't even seen them being used too much.  I 
think even now this is pointless (to me) since the flags should be able 
to do what an editorial note does in the few cases I have seen them.

Really it comes down to us needing an in-house tracker that can work 
with MediaWiki for SSO.  That is a major complaint and it is also a gap 
for people to get over when submitting a report.  At least they could 
use an OpenID for the tracker until we get SSO working which should help 
some.  If we get the module for SSO working then we can focus on having 
flags automatically create reports.  Once that is worked out, we focus 
on a comment system that uses the tracker.  This way, everything is 
centralized.  No need for discussion pages at all, as if we even really 
have one now.


[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19847

On 11/5/2012 12:00 PM, Alex Komoroske wrote:
> Thanks for looking into this, Garbee (and for setting up a demo 
> version, Frozenice)!
> Let's plan to talk about this in the call tomorrow, if you're able. 
> Switching bug tracking systems is a big decision and there are a lot 
> of aspects to consider.
> What's your thinking around what types of things we'd track in 
> buggenie? In a world where we used this system, what would we use 
> Flags/Editorial Notes/Comments for ("nothing" is a reasonable answer)?
> On Sat, Nov 3, 2012 at 4:10 PM, frozenice <frozenice@frozenice.de 
> <mailto:frozenice@frozenice.de>> wrote:
>     To take a closer look, I created a test install (no demo reset
>     timer!).
>     URL: http://webplatform.frozenice.de/bugs/thebuggenie/
>     Logins are:
>     admin / testing
>     user / testing
>     Notes: SSO seems possible to include, uploads can be
>     enabled/disabled, data can be imported (CSV), multiple projects /
>     single project, fine grained permissions, seems to use %2f in some
>     URLs (project permission AJAX) -> maybe AllowEncodedSlashes On
>     necessary, odd directory setup, issue types / fields customizable,
>     custom workflows seem nice and complex (has custom flows,
>     including linking back to earlier steps as it seems), included
>     wiki can be disabled (at least the links), has components (even
>     editions, but we don't need those I guess), VCS integration
>     possible (commit messages update bugs, github supported)
>     On 03.11.2012 02:41, Jonathan Garbee wrote:
>         tl;dr:
>         Bug Genie [1] is what we should use for task and bug tracking.
>          Any objections?
>         Long version:
>         So, I tested a handful of software today that we could use to
>         track tasks and manage bugs along with any other possible
>         Project Management things we could need.  I'm very happy to
>         say, I have found one awesome solution for us.  That solution
>         is Bug Genie [1].
>           We can use it for:
>           * Bug Tracking
>           * Tracking major content edits/additions.
>           * Tracking actions produced through telcons (perhaps even
>         the telcon discussion points themselves).
>           * Perhaps more if anything else comes up that we need to track.
>           Pros:
>           * Super granular ACL (Access Control Lists).
>           * Decent UI by default.
>           * Very customizable.
>           * OpenID support.
>           Cons:
>           * Pretty intricate setup.
>           * Lots of features that aren't too useful to us since we
>         aren't developing software.
>           * UX is tricky at first to figure out (I will try to help by
>         creating exact guides to help with tasks being done in the
>         tracker).
>           * Wiki "module" that is required.  So there is wasted links
>         around going into the Wiki that aren't needed.
>         We can use the software to track just about anything we want
>         to do. I am confident that by hosting this we can streamline
>         all suggestions, bugs, requests, and tasks into one
>         unified area. Keeping things very centralized, easy to
>         administrate, and super simple to keep track of things.
>         It would remove the use/need of discussion pages, comments,
>         and these random pages that we have scattered about for
>         tracking tasks along with the bugtracker hosted by W3.
>           I am going to setup a test install on a public server early
>         next week and import most of the bugs from one or two sections
>         of the current tracker as example data.  This way
>         everyone can try it out and see if it is worth pursuing to
>         use.  I really think that we can use it for full project
>         management for WPD and centralize a lot of information that is
>         currently spread out among duplicated areas.
>           If anyone has any questions about the software, or how
>         exactly I think we would be using it, please ask.  I really
>         think this is the best solution for us that fits the Open
>         Source requirement.  If you also know of something you think
>         would be better, please let me know so I can review it.
>         Thanks,
>           -Garbee
>           [1] http://www.thebuggenie.com/
Received on Monday, 5 November 2012 18:14:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:43 UTC