Re: obvious questions

Hi Dave:

In message
<CAETHaKrgTUcR3PB_arxKg1gvJ-ZQHMVzJ_7wWdTWwWLavzOa2g@mail.gmail.com> ,
Dave Bender writes:
>I read through the docs as well as I can, but I have some dumb
>questions that I will need to be able to answer for users.

Which tracker template are you using: devel or responsive?
I think those two have the fields you mention below.

Most of the documentation you will find is for the classic
template/schema. That is also where my expertise lies. I have designed
quite a few trackers based on it. The classic template is where most
people designing a new tracker will start.

The devel/responsive templates are meant as a starting place/example
for somebody who is doing software development. It is focused more on
waterfall/classic product management than agile methods (e.g. it has
milestones but lacks sprints).

>What makes a task different from an issue (other than the presence of
>a severity column)?

Issue is the generic term used by the classic tracker template (and
jinja2 template since it uses the same schema). An 'issue' is
something that can get update messages and is able to be tracked from
start to finish.

It looks like the devel template defines 'tasks' and 'bugs' as
different issue types.

A tracker can define multiple issue types. For example:

   https://www.roundup-tracker.org/docs/customizing.html#tracking-different-types-of-issues

defines a 'support' issue.

My opinion on task vs. bug is:

  bug - actual failure of software (or maybe misleading documentation issue)
  task - request for enhancements, possible doc changes, build system changes
         etc.

but that's just my opinion. Unlike a lot of bug trackers or help desk
software, it is not rigid. The schema and interfaces can be changed to
support how you want to work.  If you don't want bugs and tasks, you
can ignore the task issue type or remove it from schema.py.

Also the two types may have different visibility (access
permissions). E.G. bugs might be visible to the anonymous user while
tasks are not.

I took a quick look at the schema. It looks like task links to a bug.
So my guess is the intended use is:

  * that bugs are submitted by the public/customers
  * a task is opened to fix the bug.

But I am just guessing here.

Also, since multiple trackers came up in an earlier thread,
https://www.roundup-tracker.org/docs/installation.html#running-multiple-trackers might be applicable.

Generally I recommend multiple trackers when you have different
(mostly disjoint) sets of users. E.g. external customers submitting
reports vs internal staff requesting IT changes.

>I couldn't find task defined in the glossary.

'task' is unique to those two trackers and means what the tracker
author/admin/user wants it to mean 8-).

>I did find a section that suggested tasks were defined for actual
>system administration of roundup itself?
>https://www.roundup-tracker.org/docs/admin_guide.html?highlight=task#tasks

You are linking two separate items that happen to use the same
term. They are not related.

>What is the purpose of the "Milestone" item?

In traditional product management, a milestone corresponds to a
software release or other major evaluation point. The tracker template
you are using defines a Milestone issue as well. It allows you to link
completed/planned bugs and tasks to achieve that milestone.

>Milestone is not defined in the glossary section of the docs, and a
>search for "Milestone" in the documentation only shows the feature
>list.

Milestone is a standard term in Project Management:

  https://www.wrike.com/project-management-guide/faq/why-should-i-use-milestones-in-project-management-software/

If you subscribe to agile, it is less used.

https://pm.stackexchange.com/questions/22510/sprint-vs-milestone-vs-release

>Should I define Milestones before I start making lists of issues or tasks?

You don't have to. You may not even want to use milestones. If you are
more agile based, you might need a sprint issue type instead.

Milestones are larger groupings of work. Milestones can be date based
'fall 2024', feature based 'support themes user defined and packaged'
etc.

So you could define all your bugs/tasks and look through them to see
which ones make sense for completion for your fall 2024 software
release. Alternatively, you could create a feature milestone then
start defining/assigning all the tasks that need to go into that.

I took a quick look through the devel schema and 

Hopefully some others will chime in about how they set up a tracker to
support their software development.

Have a great week.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.