From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Tue, 16 Nov 2010 13:38:30 GMT
Subject: Re: Git roadmap (How read What's cooking in git.git)
Message-ID: <AANLkTim4FOixgxUjv24o9gTNqK3DWafmpNtDVMA+PS9d@mail.gmail.com>
In-Reply-To: <AANLkTimtUz3L0F_iOpH7YuYpyoutPqtevPj-Tjo6MRcs@mail.gmail.com>

On Tue, Nov 16, 2010 at 13:53, Sebastien Douche <sdouche@gmail.com> wrote:
> I'm starting a french blog[1] on git to support workshops[2]. The goal
> is to explain deeply the philosophy, the commands and subcommands,
> workflows, etc. And also to aggregate headlines of the git world,
> follow events and announce git releases. For the latter, it's a bit
> hard (for a non core developer) to follow the development. From your
> point of view, how we could set up a roadmap and a "what's new"?

Projects that have a "Roadmap" are usually the ones that have paid
developers, where someone will centrally plan what things get worked
on. Then assign developers to those tasks.

Git is a free software project. So it can't have a "Roadmap" in the
same sense.

What we'll end up implementing is a function of what patches people
send, and which of those patches end up passing review and get into
git.git.

You can get something like a roadmap just by following what people are
working on, and asking them what they want to do next.