ipatalas / vscode-sprint-planner

Plan your sprints in VSCode directly!
MIT License
36 stars 21 forks source link

Add Area #23

Closed subaltra closed 3 years ago

subaltra commented 3 years ago

When ever you publish the files are created in the main project area not under our team area. It would be nice if you can specify the area for each item so things will be in the correct place instead of having to move them after creating.

Other than that this seems great good work.

cgrisham commented 3 years ago

Second this comment. Way our company structured our Project we are all broken into our own areas and need to be able to create work items for a given area. Would love to use this extension, but need this feature before being able too.

ipatalas commented 3 years ago

Hi guys. Thanks for sharing your concerns. That all makes sense, but since I'm no longer using Azure DevOps for quite a while I need some help understanding the problem before I can dive into fixing that. Area for new tasks within a user story seems to be inherited from the user story itself so I guess the problem is only with user stories, right? It's true, area is not specified when creating user story when publishing so it gets the default of the project. It was good enough for our team back then but it makes sense to improve that and it shouldn't be that hard from what I can see.

I'd like you to share your use cases. Is it that you always want to assign all new stuff to the same area (your team area basically)? Maybe you are managing stuff for multiple teams and would like to have more control over it?

I can think of few different options - one would be to set it in extension settings. The good thing would be that it would not reset every time you open new file to plan stuff. The downside is you can't quickly change that in case you need to create US for a different team/area.

Other option would be to set it globally on file level so something like this: image It's more flexible, let's you quickly change it when needed. It can be easily overridden - this would be effective until next @Area statement so you could set area, list stories, set area again, list more stories.

Another approach would be to set it on User story level but then you'd have to set it each time which seems cumbersome and you can have the same effect with previous option in worst case (if every user story is a separate area which I think is almost never the case - correct me if I'm wrong).

Then we could go even deeper and let setting it on task level but that feels like a total overkill from my perspective.

All those options could be combined in a way that most specific one always wins but otherwise it inherits from outer scope(s) up until the global setting (or default project if nothing at all is set - backward compatibility for free).

Luckily it doesn't all have to be implemented at once. I'm not gonna lie to you - I don't have much time for this these times even though I really wish I could polish this extension because it's very promising and still lacks few things I have on my roadmap. That being said last two options seem to be the most effort. First two options seem doable within reasonable timeframe. In my opinion those two options give almost full control over the areas (except of task level areas but who does that, really?) and should be sufficient for most scenarios I can think of. Like I said at the beginning I haven't been using Azure DevOps for long time so I may have lost the feeling of how it's used so please share your thoughts. If the first two options are satisfactory then I'll try to squeeze it somewhere into my schedule.

cgrisham commented 3 years ago

For my use cases being able to set it in the configuration is a 90% solution which is more than enough to use this extension more. The times I'm creating a story for another area is the rare occasion and less likely to use a tool like this anyway.

I can certainly see a need to be able to specify the area at either the file or work item level as well, however if you managing the stories for multiple teams I can't see this tool being as useful sense it's only story and task level.

I appreciate any work you're able to put into this. After over looking the code a bit myself, I may try implementing it as well.

ipatalas commented 3 years ago

https://github.com/ipatalas/vscode-sprint-planner#setting-area-path-since-050

As mentioned before I went with first two options as they were relatively low hanging fruits. The rest is much more effort and covers only few edge cases so it's not worth it at the moment.

Let me know if you have any comments on how it works.

cgrisham commented 3 years ago

Awesome I appreciate you add this and so quickly! I'll start using it this upcoming week.

ipatalas commented 3 years ago

Ok, closing for now. In case there are any issues with that please reopen or create a new one.