Re: setting some goals

["Alex G.S." <alxgrtnstrngl gmail com>]

 

But yeah, issue tracking systems were not designed for task and project
management, but some organizations [ab]use them for that.

I probably wanted to express that having to learn a new tool requires
convincing reasons shared by the team, otherwise a tool will not be
widely accepted and effectively used in a team. 

Yeah it's usually better to use a tool specifically designed for that.  But since nothing is being used it's better if Bugzilla is used even at least temporarily.  If anyone has any other suggested systems please bring this up.  Perhaps if Oliver could run a poll we could see what systems people are familiar with and choose that.

On Fri, Jun 20, 2014 at 6:42 PM, Andre Klapper <ak-47 gmx net> wrote:

On Fri, 2014-06-20 at 18:05 -0400, Alex G.S. wrote:
>         Except for charts (what kind? Gantt? Or some "Task 4 is 14.3%
>         done" in a
>         graphical way?), this sounds
>         like http://bugzilla.gnome.org and not yet
>         like a convincing reason for another piece of infrastructure
>         software to
>         maintain,
>         IMHO. https://wiki.gnome.org/Bugsquad/ForMaintainers explains
>         how to get a Bugzilla product and/or component, if wanted by
>         the team.
>
>
> Well, after browsing, https://bugzilla.gnome.org/browse.cgi I see
> software projects, apps and code so I don't know how we could utilize
> the bugzilla for that purpose.

You wrote about the "ability to setup a sub-project" like a product or
component in Bugzilla "and have issue tracking" like a ticket in
Bugzilla and "each article could be a feature" which might be a
component or a dependency task in Bugzilla "and people could then be
assigned" which is a ticket assignee in Bugzilla.

Based on that I was wondering if a software project with subtasks,
target milestones and assignees for a task is very different from a
non-software project.
(But yeah, issue tracking systems were not designed for task and project
management, but some organizations [ab]use them for that.)

>         I'm not sure though if there's really a technical issue to
>         solve here
>         (supporting tools) or a social 'issue' instead.
>
>
> What do you mean?

I probably wanted to express that having to learn a new tool requires
convincing reasons shared by the team, otherwise a tool will not be
widely accepted and effectively used in a team.

andre

--
Andre Klapper  |  ak-47 gmx net
http://blogs.gnome.org/aklapper/

_______________________________________________
engagement-list mailing list
engagement-list gnome org
https://mail.gnome.org/mailman/listinfo/engagement-list