[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.



Reply to: