New release schedule proposal

[Antonio Terceiro]

Hi Daniel,

[would you be so kind to stop sending HTML mail?]

On Sat, Aug 10, 2013 at 07:34:02AM -0600, Daniel Tygel wrote:
> Hi Terceiro and others,
> 
>     There would be two ways to reacting to the proposal: one considering that
> it's important to have a colletive coordination, but in a different manner from
> what I suggested. And a second one (which was chosen) to just dismiss community
> coordination. That's not a good sign, in my opinion.

Please don't always assume the worst from people. Code review *is*
community coordination.

We are just disagreeing on the exact way to coordinate. You are
proposing that we discuss before writing the code, and I am proposing
that we do that after the code is written (what may be before it is
finalized and does not mean it needs to be wait for 6 months of
development).

I will try to avoid replying further in this thread because it seems
that I have a tendency to monopolize discussions here.  It's fine that
we disagree, others can read the arguments and position themselves, so I
won't discuss this to exhaustion as I did before in other topics.

>      Let me comment in your text:
> 
> Em 09-08-2013 17:35, Antonio Terceiro escreveu:
> 
>     On Fri, Aug 09, 2013 at 11:54:54AM -0600, Daniel Tygel wrote:
> 
>         Hi Rodrigo and others,
> 
>             I liked very much the new release schedule, congratulations for the work!
> 
>             Below follow some comments and suggestions:
> 
>         Em 09-08-2013 11:41, Rodrigo Souto escreveu:
> 
>             ---++ Proposal
> 
>             1. Fixed new features release time of 3 months. Changes in this time
>             should not be negotiable (after defined here) in order to maintain
>             stability.
> 
>             2. Inclusion of RC1 and RC2 versions in the official schedule.
> 
>             ---++ Definitions
> 
>                * RC1: First release candidate version
>                   * No new feature will be accepted after this version
>                   * Package released in the test repository
>                   * Conclusion of release notes
>                * RC2: Second release candidate version
>                   * May be released only if necessary
>                   * Package released in the test repository
>                   * Contain fixes for the features on RC1
> 
>             ---++ Schedule
> 
> 
>         I propose that we talk about these 2 months and 2 weeks before the release
>         start. Here are some proposals:
> 
>         . Day 0 to 2 weeks: Proposal, by all developpers in the community, of
>         ActionItems that will be included in the next release. These proposals must
>         have all information, specially who will be responsible developper, and a well
>         described definition of what will be done, adequately categorized in the
>         features categories.
>         . One moment between 2 and 3 weeks: Virtual meeting of the community, with
>         those interested, with the objective to eventually merge proposals, or discuss
>         their implementation. This meeting would be 1 to 2 hours long, and would have
>         as outcome the final definition of the sets of Action Items that will be
>         included in the next release, with the responsible developers and the eventual
>         modifications discussed in this meeting.
>         . From this "community meeting" to the release: no new action item can be
>         included in the set, except if it's an simple fix for some bug.
> 
>     I have two problems with this idea:
> 
>     - it adds explicit coordination points that depends on participation of
>       everyone interested, who might be very incompatible schedules. Try
>       scheduling a meeting between 4 people that do not already work together.
>       When "everyone interested" expands to more people, this will become
>       even more intractable.
> 
>       If we insist in this, someone who misses the meeting won't be able to
>       argue for inclusion of their code. Free software development cannot
>       depend on people being available at specific times for meetings ...
>       the coordination has to happen asynchronously using the appropriate
>       means for that: code submissions and review. Of course you can have
>       meetings for specific purposes with interested parties, but requiring
>       everyone to attend a "community meeting" to have their code included
>       is equivocated.
> 
> I could cite a large quantity of new features that were developped without
> discussion in the community and that directly affected our cirandas
> implementation. One recent example was the change of the catalog, which simply
> wiped off the enterprise menu, because colivre wanted that for a single
> implementation (redemoinho). If we had discussed this proposal ***before*** the
> code was developped, it would never be done like this, and cerainly work would
> be saved, since now someone will have to remake this error somehow. I saw that
> aurium proposed that the catalog become a block, and this would solve the
> problem, but at the same time proves that the lack of broad community
> participation and coordination made the previous work almost lost. And this
> involves costs, besides problems to the affected implementations.

I agree with you that this was a problem. However, I do think that our
proposal does address this issue. In a new release process, you would
have 1.5 month before a final release containing this code to detect
this problem. If your team also participates in the code review process,
you can even detect problems _before_ they enter the code base.

> Discussions are not counterproductive: they legitimate solutions, and give more
> energy and involvment from everybody. If we have a colective moment when we can
> establish together ***which*** action items will be approved for a release, we
> can save coding and even have more developpers in a same actionitem that could
> be of interest of more than one actor.

Discussions are fine. The problem is making a meeting -- where, again,
_will_ miss people whose schedule cannot fit that -- as the central
place of decision making. We can have community meetings, and I think we
can discuss plans and everything else. I just don't believe in the
method you are proposing for taking decisions.

> I don't believe in simple technocracy or meritocracy.

It would be nice to avoid labels, otherwise it might look like you are
trying to use rhetorics tricks to disqualify my arguments.

> Decisions about next features and how they are implemented are more
> than that: they're also political decisions on how noosfero will
> evolve. Up to now, these kinds of decisions (like the pluginization of
> solr, which did ***not*** result in better performance of noosfero)
> are being made solely by colivre (and now the implementations that
> don't install solr simply don't have a decent search plugin, on the
> contrary: see the softwarelivre.org platform, for example). If these
> were more collective decisions, we could have much more synergy,
> sympathy and legitimacy in all processes.

If people actively review each other's code, propose changes, make
technical discussions together, there will also be synergy, sympathy and
legitimacy on the process. The way you put it is like you are proposing
a beautiful and democratic process and I am arguing for a gray,
technocratic and excluding process.

> I don't think that the definition of what actionitems to one release should be
> decided solely by so called "technical conditions", since the "technical
> conditions" can be very different to each party. Yes, it's important to have it
> very clear that a developper is assigned and an actor is responsible to
> developping the actionitem.
>
> If it's too much to have the decision of the entry of an actionitem (yet to be
> done) in the same development cycle, the schedule could then have this
> community meetings to define the new features of the ***next*** cycle, and the
> actionitems in the same cycle would have to be those already defined in the
> cycle before (so almost 5 months before) and that already were developped and
> had a merge request. If this is a better solution, no new features could be
> developped in a whole release cycle: only bug corrections and fixes for already
> developped action items would be done in the 2.5 months before the release
> candidate. Well, it's a possibility.

A problem with your idea is the assumption that a feature can be
developed during a single release cycle, or even during 2 release
cycles. As much as you wish you could, you can't know that in advance.
At best you can try to guess, but will often miss the target.

> But my question is: ***who**** decides what action items (of new features or
> changes in existing features) are going to be in a release?

Exactly, and that is a problem with your proposal: it requires deciding
stuff about the future, and requires deciding upfront who decides what
gets approved for development or not.

> ***How*** can we
> know that these new features (or changes in existing features) will not create
> problems to one implementation or others? Well, I think that only the community
> knows that. There is no "superpower" capable of knowing how each implementation
> is thinking its future.

Agreed, but it doesn't mean that a democratic meeting is the only way to
make sure we don't step on each other's toes. If the interested parties
take part in the code review, they are able to catch problems before the
code is accepted. They will also have plenty of time between an RC1
release and the final release to catch that, and for instance decide to
not upgrade before the issue is resolved.

Note that when I say "code review", it does not necessarily mean only
reading the code. People can run an instance from that code, check how
the user interface was changed, how the new features impact the existing
systems etc etc.

> Therefore I think that the release schedule should have ***some*** official
> moment where formally the community is legitimating a release. If my specific
> proposal is not viable, I'm totally open to other alternatives (votes? e-mail?
> etc). But I don't think that community should be simply a place to share, but
> also a way to actually decide things about the noosfero releases. It will make
> noosfero way better (in my opinion).
> 
> 
> 
> 
>     - it assumes counting on code that may not be written yet, what adds a
>       level of uncertainty to the process.
> 
>       "OK, we decided that feature X will be developed by developer D and
>       will be included in the next release. What if D₁ falls sick and
>       doesn't finish in time? What if D₁ finds out that the implementation
>       is a lot more difficult than expected? Well, now we already planned
>       the release with this feature, and feature Y that is being developed
>       by D₂ would only make sense if X is already in ... oh well".
> 
> There is always a level of uncertainty. If I understand your example, it means
> that in a cycle, only features that were ***already coded*** will be added.

Yes.

> So what will be done during the 2.5 months of development? only code
> correction and bug fixes? 

or writing the code to be included in the next release ...

> If so, let's decide about the actionitems that will be in a next
> release one cycle before. So my community meeting proposal would happen in the
> beginning of a preceding cycle, giving almost 6 months for development of an
> actionitem. So t would be already approved by the community, and in the next
> cycle it would be in the list. I don't think that the logic of discussing
> something ***after*** it was developped is a good idea, since it can mean
> refactoring.

The review process does not need to be after 1 year of work. If someone
has a very preliminary prototype it can be submitted for early comments.
It doesn't have to be black or white.

> Some minimal planning and looking ahead, and also gathering
> legitimacy from the community is very good to give the developper the trust
> that he or she is doing something good for the platform, and that will not be
> useless after a simple evaluation that it wasn't a good solution after it was
> done.

There is no one arguing against planning. We are talking about different
types of planning, either complete up-front planning, or planning
iteratively and only making definite decisions about concrete software
instead of just unimplemented (and therefore possibly unfeasible) ideas.

> And, yes: everybody can be sick or die. That's the uncertainty of life. Cutting
> this "level of uncertainty" is rather impossible.

Nobody said anything about dying. You sound like a very negative person. ;-)

The point is not adding dependencies based on assumptions that are only
guesses (i.e. that someone's work will be done)

>     Why don't we do the opposite: instead of deciding about code that
>     _would_ be written, we decide about what was already written: if it was
>     submitted and approved during the period where it's OK to add new
>     features, and it does not mess with unrelated features, it's in. It it
>     missed the date, it has to wait for the next release.
> 
>     Everybody knows when they need to have their code ready for inclusion in
>     the next release and can plan accordingly. If they miss a release, they
>     know when is the next.
> 
>     If there are dependencies between features, only the people involved
>     with that features need to coordinate, instead of having to involve
>     everyone.
> 
>     We can even increase the length of period where only bug fixes are
>     accepted, having a 1½ month merge window and 1½ month of bug fixes only.
>     Whoever adds code who turns out to be broken has to fix it between RC1
>     and final release.
> 
> As I said, this could be an idea: to have in a release only fixes and
> corrections. But then an alternative would be to have some legitimation of the
> would-be features in the cycle before.

I didn't propose that. The idea I suggested in this snippet -- slightly
different from the original proposal -- is that the first 1.5 months of
the release cycle would be period during which we accept new features,
and them the final 1.5 months would be for testing, fixing bugs
(specially the ones introduced by any new) features and assuring the
quality of the release, instead of having just 2 weeks to fix stuff.
Maybe 50%-50% is too much, we could have a merge window of 2 months and
then just 1 month of stabilization. I hope you get the idea.

Releases that only contain bug fixes already happen in parallel with the
releases that contain new features, and we are not discussing that.

> My proposal doesn't dismiss the good practice of the actors particularly
> interested in a specific feature to coordinate. This is already starting to be
> done, thanks to the result of the last FISL. That's ok. I'm talking here of a
> community decision-making of what new features will be in each release,
> depending on many factors, including technical maturity of the code, of course,
> but also the appropriate solution for the feature, which would have to be done
> before the developper puts its hand on code. This ***saves work after***.

In my opinion we disagree in a very fundamental level: you believe in
separated design and implementation phases, and I don't.  My vision is
that design and coding are intertwined and you can't disassociate one
from the other, and that is why I think it is not practical to decide on
inclusion of features based on pure ideas.

As much as you try to paint our disagreement as democracy versus
technocracy/meritocracy, it is actually a _technical_ disagreement.

The proposal we are making is based on models that already work pretty
well in projects as Linux, GNOME, etc. I believe we have some experience
with free software development and software engineering in general to
know that completely upfront planning does not work. YMMV.

-- 
Antonio Terceiro <terceiro at colivre.coop.br>
Colivre - Cooperativa de Tecnologias Livres
http://www.colivre.coop.br/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://listas.softwarelivre.org/pipermail/noosfero-dev/attachments/20130810/a8d5c814/attachment.pgp>