gtg team mailing list archive

[Bertrand Rousseau <bertrand.rousseau@xxxxxxxxx>]

Hi everyone,

Needless to say, GTG know quite a good growth in success. I don't have
actual numbers, but the numbers of bug reports, contributors, merge
requests shows... This is great, and it sure warms my heart, even more
when I know that one year ago we had just what looked like a prototype
application to share. But this is also a problem since all this
activity is quite overwhelming, and it's becoming hard to keep
everything in control. For Lionel and I, it means a lot of  catch-up
and debate, and that very often lessen our possibility to directly
contribute to code, or to hack new things.

In the past days, some of us had several discussions about the current
state of the GTG community, etc. We requested the advice of some other
developers, to get a feedback and some advices on how to handle that
issue. We had some pretty interesting feedback, and I'm writing this
mail today to start the discussion and hopefully to decide some new
way of working with our community.

Those following suggestion keept my attention (feel free to add yours
in your response):

 - have a roadmap: we definitely have to agree on the several
development steps we want to reach. A roadmap is the perfect solution
for that: it allows to lay down our intention as developers, and it
allows to give priorities to them. That way, it keeps a group of
developers focused on the "next big thing" to do. This roadmap should
be public, so that everyone know our priorities, and motivated
contributors can start working on less prior tasks, that way, it keeps
the contributed work useful. I think having a "Roadmap" page on our
wiki is the way to go.

 - have some kind of guidelines/"manifesto": we should try to lay down
some core thoughts and perspective about the way we think GTG ought to
be developed. That way, that would help developers, triagers and
contributors to know that their contribution will likely be accepted.
Knowing beforehand that it goes against our views, having those
guidelines would avoid energy-sinks like endless debate on feature X
or Y if it's an inappropriate contribution. Once again, our wiki page
is perfect for that.

 - a place to discuss ideas and mid-term plans: we also need to debate
on some design *before* it reach actual code, or - at least - merge
request. It's important to have a tool that allows to test solutions,
without the burden and the pressure of integrating too quickly
experimental code. I guess we could try using launchpad blueprints for
that, since they should be a convenient way of discussing design issue
at a relatively higher level than bug reports. For instance, they
would be perfect for Lionel's backends proposal.

 - a place to integrate cutting edge/prototype code:  Having some kind
of experimental branch could help too. Maybe we could move towards
this scheme: a "stable" branch (i.e.: 0.2 right now), with minor
revisions integrating critical bug patches, an "instable" branch
(i.e.: 0.3 right now) integrating more new features, but already
discussed ones, and an experimental branch (not present right now)
that would have a very low-filtering level, and allow for on-the-edge
testing.

So these are my ideas so far, please don't hesitate to share your
point of view about it. So far, this would imply those decisions:

 - create and write a roadmap page on GNOME live GTG page
 - create and write a guideline page on GNOME live GTG page
 - start discussing some midterm work (from the roadmap) on launchpad blueprints
 - create an extra "experimental" branch on launchpad + create and
write a mail + a page on how development work in GTG

Have a nice day!

-- 
Bertrand Rousseau