Re: Telcon action: Task management proposal

Thanks for this write-up! Garbee, hopefully you'll be at the call tomorrow
and can give the live version to help spur the discussion.

On Mon, Nov 5, 2012 at 10:14 AM, Jonathan Garbee <jonathan@garbee.me> wrote:

>  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> 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/
>>>
>>>
>>>
>>
>
>