Re: Bug#830344: How should the TC help with a project roadmap?
(I noticed that you replied to the list, and not to the bugreport. I
took the liberty to send my reply to the bug as well to have a complete
log of the discussion. Feel free to drop the list in the subsequent replies).
On 04/08/2016 22:22, Tollef Fog Heen wrote:
>
> One thing I don't think we're in complete agreement about is which
> problem we're trying to solve with the roadmap. Is it to gather
> enthusiasm? Is it to steer Debian better? Is it to communicate to
> commercial partners like HPE? Something else? I think we need to agree
> on that before we try to agree on the mechanism to achieve it.
>
This is a very good question indeed. The main goal of the roadmap is
none of those. What you listed are desirable (and expected) side
effects. The main goal is to document time-limited technical sub-projects
that might need more promotion and/or more manpower.
As I described it during my talk, a roadmap:
- reveals gaps between what we do and what we should be doing
- provides a strategic view, a vision to the project
- is a communication tool
- can be a recruitment platform.
Having a roadmap published, I expect us to:
- find new contributors by showing that our work doesn't focus solely on
packaging. For example, porting [1] efforts are funny problems for programmers
and I am not sure those easily find how to start in our project.
- give some insights about what we are doing and what we are planning to do
- be able to approach partners and potential sponsors with a concrete work plan
- an easy way to communicate about what we do (and about our progress)
I believe those are valuable goals and a roadmap will help us to achieve them.
[1] By porting, I mean both adapting code to work on new architectures and
migrating some code to new versions of some libraries.
Regards,
--
Mehdi
Reply to: