- From: Jonathan Garbee <jonathan@garbee.me>
- Date: Mon, 05 Nov 2012 13:14:19 -0500
- To: public-webplatform@w3.org
- Message-ID: <509801FB.5080002@garbee.me>
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
site.
* 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
completely.
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.
-Garbee
[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