Priority needs to go to topic level

[buildingsmart]

Priority needs to go to topic level

[lbj]

The reason why status and priority is on the comment level is to preserve the history. Priority might change and its useful to know who did it and when it happened. By moving it to topic-level we loose this information. I disagree in moving it unless we come up with a better way to preserve the history for everything that happens on a topic.

[theoryshaw]

Is there a precedent for 'priority' at comment level? I don't remember seeing one, in all the Issue Trackers I've worked with.

Perhaps a decision here, can be informed by what is typically done (or not done) with a typical issue tracker.

[teocomi]

Most of the Issue Tracking systems I have seen have priority and status at the issue level, and they store the issue history somewhere else.

BCF could store these changes in the form of comments eg: " Status changed from Open to Resolved" or by adopting an (optional) history field in the markup eg:

<history>
   <action property="Status" valueFrom="Open" valueTo="Resolved" author="[email protected]" date="xxx" />
</history>

[ErikPijnenburg]

Lars,
If you really want to be able to preserve history of topics via comments (which I totally disagree upon) then we miss a lot of stuff in the BCF 2.0 definition. How do you want to keep track of changes in topic level properties like topic title, topic-labels, assign-to, etc. with the current format? Or the example tecomi gave in issue #27 here in github ?

This problem has been discussed already when we decided to move status and type to topic level in October/November last year, see issue #6. Let's hope we are not going to repeat that.

So BCF 2.0 file format is not suitable to keep track of history and will never be unless we load it with lots of extra stuff or change it into a database.... It is clear to me (and some other I suppose) that we will need a hub for keeping track of history....

If everybody understands this, then we can move to the next level in this discussion and clarify he meaning of a BCF file format:

• BCF 2.0 file definition is just a basis for the BCF data definition
• in near future most applications will be live inked to a hub.
• Thus the BCF file format needs to carry enough information to make communication possible from a hub to off-line applications and back in such a way that the hub can keep track of history...

For this last purpose we already miss information in the BCF 2.0 definition.... see my other recent posts how to solve this.

[pasi-paasiala]

I agree with Erik, We cannot maintain the whole history in BCF file format. For that a hub is needed.

[pasi-paasiala]

In telecon 2014-07-17 we decided to move the priority to topic.