thanks - I'll upgrade!

thanks - we'll give this a go. It's not clear how often people will need to use this so I agree with your concern about UI clutter.

this will work just fine, thanks!

thanks, this worked for me!

thanks, I didn't think to use containerPHIDs, I'll give this a go this coming week and let you know if it works for me. Thanks!

ok, that was the problem - default values will cause a field to show up in the 'details' section, thanks!

ok, so the intent is that any initialized field shows up in details, but no others? If so, then do fields with default values show-up? I have a software version field for example has a default of 0.0.0 and it shows up for subtypes for which it's hidden. Here are some screenshots to show you:

We currently display the description in the reports we generate and those reports are themselves markdown, our tools currently upload these docs to phriction.

I'm now using this and it works well! I've noticed one wrinkle that I don't understand, namely, the 'Details' section when viewing a task includes some custom fields and not others? In particular, it includes custom fields that are hidden for the current task subtype. Is there anyway of controlling what appears here?

I can confirm that advisory locking is acceptable. Locking the whole task is preferable, but we can live with comments not being locked. Thanks!

sure, I'm fine with letting the dust settle after these changes and deciding then. The edge.search approach would be totally fine since I'm writing a custom client, also, the attachment approach would work since our set of related tasks will be small for the foreseeable future.

Q. Common or rare?
A. Common - we'd lock all tasks before a release.
Q. Lock comments? Do you need to lock comments too, or just other types of edits (like status, priority, title, description, etc)?
A. I'm ambivalent about this, if the lock is mandatory then being able to add comments seems reasonable since someone can point out that the task needs to be unlocked for some reason or other.
Q. In particular, could a solution where anyone could unlock the task be acceptable, as long as they had to explicitly unlock it? Or is it a hard regulatory requirement that unlocking requires some sort of administrator/oversight step?
A. Unclear, I'll ask, but it's probably fine since there's also a 'process' that states how people use the system. (And you'd be surprised how much drama there is inside private companies:-) That is, our conventions are formally documented and people expected (and expect) to follow them.
Q. Lock other objects?
A. Possibly, but I've been pushing back on it for things like code reviews by arguing that 'everything is logged and there's an audit trail' so what does a lock by us? Obviously locking git doesn't really make sense and new comments can't hide old ones so I don't see what the problem is. For tasks, I don't feel I can make that argument since people will naturally just look at the current state of the task unlike code reviews where the history is 'in your face' as it were.

thanks, sounds great!

"Overall, I think this is the model we should continue under, and task subtyping should be implemented in terms of views of a subset of fields."
"In the current model, you choose a task type first, by selecting a "Create" form, not by choosing from a "Type" dropdown within the task. "

I think it's fine to disallow changing from one type to another - can that be enforced? And sure, I think the custom form approach would work but I don't see how to configure/use that - can you point me in the right direction? I presume this implies that the underlying fields are the union of those exposed by all of the forms which would be fine.

I am currently using project.query rather than project.search. I presume the change you suggest for .search would work for query too since my recollection is that project.query also doesn't return milestones. I tried to use .search originally, but noticed that the attachments available were limited and didn't correspond to the documentation (examples mentions projects, subscribers, but then later on only watchers and members are supported) so I was scared off by the 'may change' warning:-) I can switch to using .search if that's the better thing to do - I presume you'd add attachments for the new types of information to be returned?