Are you sure it is what you expect ?
If locked, ticket will not be updatable unless unlocked.
So resource working on ticket will find it hard to deal with unlocking / locking to trace all changes on tickets.

Wouldn't it be better (more complex I guess but much better) to be able to "fix scope" of a version :
=> items tagged with this target version not able to chenge version
=> no new item allowed on this version
With some kind of explicit message : "this version scope is fixed, cannot move or add any item to this version"

you still can modify ticket content and modify the scope of the project this way unfortunately, so I would prefer to lock ticket

What do you mean by "scope of the project"

This is simple: scope of the project based on the tickets->requirements. Modifying ticket you modifying scope of the project

Hi all,

couldn't it be solve with "read only" access?

Klaus

In this case people will never able to add comments, analysis, or change the status for example...
It is easier to lock when ticket confirmed and selected for the project and unlock to close it

I see the point. That's correct.

In this case people will never able to add comments, analysis, or change the status for example...

Neither will it be possible with locked tickets ...

It is easier to lock when ticket confirmed and selected for the project and unlock to close it

But how will developers be able to work on ticker ?
=> start work
=> add comments
=> resquest for notes for completion
=> change status
=> enter result description
...

I understand the need, but am not sure locking is the answer.

That is the object of my question :

What do you mean by "scope of the project"

It means, instead of locking, it could be better to "fix scope".
But what would it cover ?
Fix description section...
Fix target version ...
Fix links ...
Not fix result...
Not fix status...
Allow new notes...

Lock will be done only by project manager. So, when ticket status is work in progress it will be locked. Any changes after that need to go via PM who will unlock it when necessary. This will guarantee that PM is aware of the changes proposed not after it done - with a lot of mails coming it is easy to miss this kind of things
Usage is optional anyway...

And what did you say to following:

Change of Ticket should raise an event to send mail like status change or new note.
Then you get an information on change and can check, whether you agree or not.

I as project manager wouldn't lock or unlock all my Tickets - that's to much overhead for myself's daily work.

Klaus

I already answered on that - see previous message: " with a lot of mails coming it is easy to miss this kind of things"

If I had to decide between an info mail or an Lock and Unlock of Tickets, I would prefere the mails.

If you have not a lot of activities running - yes but with a few hundreds of them?

I understand the need, recorded it as ticket #1015.
But I am not sure locking is the answer.

In this case people will never able to add comments, analysis, or change the status for example...

Neither will it be possible with locked tickets ...

It is easier to lock when ticket confirmed and selected for the project and unlock to close it

But how will developers be able to work on ticker ?
=> start work
=> add comments
=> resquest for notes for completion
=> change status
=> enter result description
...

That is the object of my question :

What do you mean by "scope of the project"

It means, instead of locking, it could be better to "fix scope".
But what would it cover ?
Fix description section...
Fix target version ...
Fix links ...
Not fix result...
Not fix status...
Allow new notes...

Developers mainly working on the Activities/Tasks created for Ticket, so the main changes will be in the tasks not in Tickets. In our case there never been any work done directly on ticket without task. "Scope" of the project is a part of the proposal document (which is approved) and it list all the tickets selected for project. So, if ticket is modified the scope automatically changed but not otherwise...
If status can be left 'not locked' it will be excellent.

The idea I have from your request is to have some "scope fixing".
It may fit some need I have heard of 😉

As I imagine it :
- Add a button "fix scope" on a version :silly:
- When scope of a version is fixed :
=> no new item can be linked to this version as target version
=> no item can be removed from this target version
=> "Description" section is locked for all items linked to this version as target version (not only tickets !)
=> "Treatment" section is open for all items linked to this version as target version, except "target version" :P) and possibly estimated work, priority, initial due date time and some others to define.

This way you really fix a scope :
=> not only fix some elements, but also fix the list of the elements in the scope
=> not blocking resource to continue to work on elements of the scope

What do you thing about this solution ?

Have you read this: "Scope" of the project is a part of the proposal document (which is approved) and it list all the tickets selected for project. You are trying to freeze the scope by freezing items in it but you need first define the items list, what to do if estimates required updates? another problem you should address - what about Agile: after iteration completed there can be changes. I think it much simpler to have an option to lock ticket description and links

Hi all,

from my pov Tickets are not a requirements and scope management. Hence I wouldn't "missuse" this for this purpose.

If we have requirements, we collect them and assign them to a target version. But as every body knows, scope is dynamically and so in the course of our change management, we have to add new or to change or to reject requirements. Locking the target version is possible most of the time in a very late point of time - mostly during sign off process before go live. Locking requirements is very good as it is already implemented.

Means, for us the proposed suggestion doesn't bring any value - even it seems a good approach :blink:

Please correct me if I'm wrong.

Klaus

"Scope" of the project is a part of the proposal document (which is approved) and it list all the tickets selected for project

Well, yes, this is your way of working... :huh:

You are trying to freeze the scope by freezing items in it but you need first define the items list

My proposal is to fix the list, because scope is first list of items. It seems to me more accurate than "locking" tickets : with locking tickets, a ticket could be added in the scope... 🙁

what to do if estimates required updates?

In my proposal, treatment can be updated, and notes added ! This should cover this case. 😉

another problem you should address - what about Agile: after iteration completed there can be changes

In agile, a version should just be a sprint : short version... The complete version cannot be defined at startup (as it is agile ) B)

I think it much simpler to have an option to lock ticket description and links

I'm not sure it is the solution that will satify most situations. It is the simplest to implement but may be confusing for thoose who don't need it.

"My proposal is to fix the list, because scope is first list of items. It seems to me more accurate than "locking" tickets : with locking tickets, a ticket could be added in the scope..."
- This is exactly what I am talking: the list is fixed (and approved) but it can be silently modified by modifying the content of the items in the list (Tickets). So, you cannot add ticket because the list fixed in scope but you can modify the one of the tickets, so the scope actually will change!!!

But how do you define the list in the tool, and be sure it is not changed ?

It is in the approved document (project proposal)