vscode-sprint-planner
vscode-sprint-planner copied to clipboard
Feature Request: Add Child / Parent for all items
Some project frameworks need milestones to be user stories and the other user stories the work is delivered against are owned by sprint team members. It would be extremely handy if one could add this in the snippet or in the items after they are created.
Hi @chinmaydeo-ms, can you elaborate what you mean? I didn't get what you were trying to say.
@ipatalas - not the OP, but I think I understand what he's getting at. This I think is related to #10 . Essentially, it would be cool since the items we're adding to the backlog are PBI's (in the case of the scrum process), if we could easily have those linked up to a feature, or in the case of #10, actually create them inline too.
So an example in the plan file would be something like:
Parent#0123: <provide search/autocomplete the title on entry>
This would then be able to provide a context for the items in that file, so that they can all be linked with a relevant "parent" upon creation.
However, looking into this, I guess it raises a suggestion for the plugin's next major version - standardizing the "contextual" syntax vs the "defining" syntax. What I mean by that is for Iterations, your syntax is defined as:
IT#<Id> - <Name> - <Full Path>
Based on the readme.md though, unlike area path, this one is described as being at start of file, so just based on the readme, does that mean it doesn't allow you to specify it at other times in the file, like Area:
Area: <Name 1>
xyz
Area: <Name 2>
If it does, then it seems an update to the readme to clarify that might be in order. But back to my original point, it seems that there's two conflicting conventions for declaration of "contextual" information (all caps shorthand with id vs pascal with just name). I suppose a nice iteration would be to see a convention/standard introduced, which may make it easier to add in more of these contextual items in the future. Maybe something like:
> Area: <Area Name 1>
> Iteration: <Iteration Name 1>
> Tags: <Tag 1>, <Tag 2>
[items]
>Iteration: <Iteration Name 2>
> Tags: <Tag 3>
[Items]
The concept here being that all context values (prefixed by > are carried/applied to the items under it until overriden/redefined by another context specifier. For example, I also added a new context provider - tags to show the convention following forward (pascal name for thing, fully qualified name for value).
Regardless of the above notes, I really love your extension and hope you're able to find some of the time you were hoping for previously (you mentioned having been pulled away in other issues). I really do love what this extension can do so far and can see with a few small improvements it could make a drastic improvement on my productivity!