> For tagging / monitoring, I'm ok with having the default = NO, but
> for the official bug tracker, I would like it to be YES. The reason
> is that I want any activity done a user on an old issue to cause it to
> go to the top so that we can see it. This may be less of an issue
> once the voting feature is added and it updates the timestamps as
> customers vote for the features.
I think this would be a weak technical solution for a social/workflow problem.
In my view the problem is that there are 2480 open issues and there is now workflow how these should be prioritized.
The "tagging/monitoring -> update" suggestion would be a valid workaround. But I think a weak one,
1. as there may be important open issues got lost by this
2. and it could lead to users tagging/unmonitoring/monitoring their issues to keep them at the top :-)
My suggestion would be that it should be an important task of the workflow that whenever some developer looks at a bug he should change it from new->acknowledged and tries to set a priority. Bravely. A wrong priority is better than none.
Then ordering could be done by priority.
Perhaps you could also ask for supporters that help only for this specific task: Prioritizing issues.
Tobias
P.S. Thanks for mantis!
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@...

Hi Peter,
Thanks for your help with the SOAP API. Replies inline.
On Thu, Jul 3, 2008 at 11:15 PM, Lanser Peter <peter@...> wrote:
> Hi,
>
> at present there are many problems with MantisConnect (especially with
> 1.2.0).
>
> Next week I shall have a reasonable time to work on those issues.
>
> Regarding backward compatibility:
>
> - What sould we do with the due-time attribute? Should this field be added
> to the issue_data structure?
[Victor] New issue fields should be added the issue data structure.
However, we need to handle the case where this is not visible to the
user or totally disabled.
> - How do we deal with the new category structure? Keep the category string
> and add an additional object-ref structure (id-string pair)? Should the
> category string be replaced?
[Victor] I can see two options:
a. Add category2 which is of type objectRef and continue to return
category as string.
b. Add category_id of type integer and continue to return category as string.
> - Additionally we need a new webservice call to fetch the id-string pairs
> for categories (currently mc_project_get_categories returns an array of
> strings).
[Victor] Add mc_project_get_categories2().
> Regards,
> Peter

Hi Paul, Gianluca,
I had a quick look at the code and following is the current behavior
before my changes:
1. Update issue header information (which required update threshold, yes)
2. Sticky (no)
3. Monitor (monitor/unmonitor: no)
4. Tag (attach, detach: no)
5. Relationship (add: yes, delete: no)
6. Notes (add: yes, delete: no)
7. Attachments (add: yes, remove: no)
8. Voting (once it's completed)
9. Move issue (no)
10. Clone Issue (if relationship added, then follow relationship
model, otherwise no)
11. Assign/Change Status (yes)
12. Sponsorship (add: yes, delete: yes)
Some general thoughts:
1. I don't agree about only updating the last modified time when the
update issue threshold is required, since this would exclude notes
which are the primary means of providing customers with update.
2. I generally think it is a good idea to have consistency between add
/ remove operations.
3. I don't mind having the time stamp update behavior for each action
(e.g. tagging, relationships - not add/remove) controlled by
configuration options. However, we still need to figure out the
defaults.
4. For tagging / monitoring, I'm ok with having the default = NO, but
for the official bug tracker, I would like it to be YES. The reason
is that I want any activity done a user on an old issue to cause it to
go to the top so that we can see it. This may be less of an issue
once the voting feature is added and it updates the timestamps as
customers vote for the features.
5. For companies that want to find issues that are not updated within
the last week, I think they should determine the effective last
updated time based on the last note by a staff member. For example, a
custom asking about the status of the an issue via an issue note is
not considered an update. In my opinion, for such companies, any
change to the header information should also be accompanied by a note
to the customer. However, these customers can also tune the
configuration options that determines what updates the timestamps and
what doesn't.
6. Sometimes we call bug_update_date() in the action pages and
sometimes in the APIs. I think we should move all such updates to the
APIs. If there are scenarios where we don't want to trigger the
update, then we should add a parameter to the API. This will derive
consistency, so that if an action is done via the web interface / SOAP
API, the behavior will be similar.
Now that we have the details above, lets see the feedback.
On Mon, Jul 7, 2008 at 12:01 AM, Gianluca Sforna <giallu@...> wrote:
> On Sun, Jul 6, 2008 at 10:57 PM, <paul@...> wrote:
>> if a user monitors/unmonitors an issue, the issue itself isn't being
>> updated so i'm not sure this should touch the bug itself.
>>
>> If someone had a policy of ensuring customers were updated on an issue at
>> least once per week, you would achieve this by looking at the last_updated
>> date - I wouldn't therefore call someone 'unmonitor'ing an issue as a
>> progress update...
>>
>> Am I way off, or should this be reversed/configuration option?
>>
>
> I think I agree with you here. We probably need a clear list of what
> constitutes an "update" for a bug and what does not.
>
> FTIW, I think a bug is updated when actions that requires the
> update_bug_threshold are performed.
>
>
>
> --
> Gianluca Sforna
>
> http://morefedora.blogspot.com
> http://www.linkedin.com/in/gianlucasforna
>

On Sun, Jul 6, 2008 at 10:57 PM, <paul@...> wrote:
> if a user monitors/unmonitors an issue, the issue itself isn't being
> updated so i'm not sure this should touch the bug itself.
>
> If someone had a policy of ensuring customers were updated on an issue at
> least once per week, you would achieve this by looking at the last_updated
> date - I wouldn't therefore call someone 'unmonitor'ing an issue as a
> progress update...
>
> Am I way off, or should this be reversed/configuration option?
>
I think I agree with you here. We probably need a clear list of what
constitutes an "update" for a bug and what does not.
FTIW, I think a bug is updated when actions that requires the
update_bug_threshold are performed.
--
Gianluca Sforna
http://morefedora.blogspot.comhttp://www.linkedin.com/in/gianlucasforna