Closed matthewfeickert closed 5 years ago
I like it, but would probably just put it into the root of the repo
If we keep it in the ROOT, we'd have to have multiples for each year basically which is somewhat unwieldy.
If we keep it in the ROOT, we'd have to have multiples for each year basically which is somewhat unwieldy.
Yeah, I also named it by year in PR #563, and moved it into docs
. @lukasheinrich I'm open to suggestions on alternative locations.
...though, alternatively, if we did keep in in the root of the repo we can just name it ROADMAP.md
and then when that roadmap is done archive it by moving it to a date named file. Though this feels like a bit of a "bad" thing to do in version control land. :/ I don't have strong feelings one way or another though.
Is there any objection in me also adding the mermaid .mmd
file that I made to generated the Gantt chart version of the roadmap?
@lukasheinrich Given your comment on the PR I'm fine to move the file to be ROADMAP.md
in the root of the reop.
Question though: Do we archive the roadmap after we've finished the 2019 into 2020 roadmap? Or do we treat it like any other versioned file and just replace it with the 2020 roadmap?
can't we just append 2020 to 2020 it and have a running roadmap?
I'd be fine with a running roadmap.
Hm. Maybe I need to go look at other projects roadmaps, but in my mind a roadmap is something that outlines for a specific project (development from 2019 -> 2020 inspired by IRIS-HEP goals) inside of an organization (pyhf) that has a clear endpoint/goal to it. After that, a new roadmap should be made.
Like I said though, battle tested (or any type of) project manager I am not, so I should go inform myself on how orgs like Jupyter or Binder do their roadmaps.
At the risk of being rude by asking for extra work from him, I'd be quite curious to get @choldgraf's opinion here.
From looking at JupyterHub's roadmap (which Chris mostly wrote) and the discussions on BinderHub's roadmap Issue my guess is that what we currently have isn't what might be considered a "roadmap" in the Jupyter sphere of influence as we give specifics. I'm not quite sure what it would be then other than a list or the steps to complete milestones. But I can say that getting feedback is quite welcome.
My guess is that @BenGalewsky would also have useful thoughts on this.
Just a quick thought from the JupyterHub perspective - I think that choosing the role of the ROADMAP and signaling that role is important. As you mention, there are different flavors of roadmaps - the JupyterHub community explicitly does not make those roadmaps a "commitment" to features, or timelines. This is because as a volunteer community we cannot guarantee that any one feature will be worked on at a moment in time. However, we hope that using the roadmaps will tell people "these are things we're interested in" and encourage people to give a shot at implementing some features over others.
That said, many projects (particularly ones with more resources or a dedicated project manager) do treat their roadmaps as a plan for deliverables. This can be a good way to keep yourselves to a specific deadline, it just didn't fit our particular team structure.
can't we just append 2020 to 2020 it and have a running roadmap?
I'd be fine with a running roadmap.
After doing more looking at roadmaps I now agree with you that we can treat it like any other version controlled document and there doesn't need to be anything special about it. I've changed this in PR #567 now.
That said, many projects (particularly ones with more resources or a dedicated project manager) do treat their roadmaps as a plan for deliverables. This can be a good way to keep yourselves to a specific deadline, it just didn't fit our particular team structure.
Thanks very much for sharing your thoughts and experience with us, @choldgraf. Your comment is quite helpful in helping think about project planning as well as communication between us core devs and our users.
To make it easier to keep track of the state of the roadmap in Issue #561 I was thinking of making a
governance
directory and adding the roadmap asgovernance/ROADMAP_2019.md
.I personally think it would be easier to have the
ROADMAP_2019.md
be the state of "truth" and have PRs that are part of the "pyhf 2019 into 2020" project tick of their part in the roadmap. This also makes the roadmap exist outside of GitHub, which is probably also good.@lukasheinrich @kratsg Thoughts on the pros and cons of this?