always assume good faith

[Antonio Terceiro]

On Mon, Jun 23, 2014 at 12:29:30PM -0300, Bráulio Bhavamitra wrote:
> > > We at EITA have a proposal about that we are yet to publish to the
> > > community.
> >
> > Sure, let's look at it. I have thought myself sometimes about just
> > opening the gates and letting everyone just commit the hell out of the
> > repository, but I am still not convinced that it will be any better than
> > the current status.
> >
> Please don't go to the extreme, *again*.

err, I didn't actually mean "everyone" literally

> > But maybe, no amount of discussion will convince you that you could be
> > already doing 99% of the work instead of insisting that you need
> > permission to do the remaining 1% before you will be willing to do the
> > first 99%.
> >
> Please look again to the fact you stated on the begginning, and to your
> experience with free software, in *practical terms*, *not theorical and
> possibilities*.

I am being completely practical here. The current policy is: first you
need to care, *then* you receive the permissions you need to *finishing*
the work you already do. This _is_ how other (but of course not all)
projects work, and I _have_ contributed to projects where I did _all_
the actual work and had to wait for someone to "approve" my work before
it got to the repository.

The way you want it to be seems to be the opposite of that: first you
get permission, then _we hope_ you will start to care about what comes
before the point where you actually need those permissions.

Note that I don't think there is anything wrong with either way; I am
just not convinced that a change will do us any good. Maybe trying won't
hurt.

What I mentioned that I had thought as a possible change in the current
policy was giving the benefit of the doubt to the people who have enough
contributions, even though they never helped with code review; give them
commit access, and _hope_ they will start helping to review incoming
code.

Maybe I am too pessimistic and I am worrying about the worst case, which
is people just pushing the changes they want directly and not helping
with code reviews at all. That could probably be avoided by putting up a
"rule" that each commit has to be reviewed by at least 1 committer that
is different from the author of the commit (save extreme cases such as
critical bugs where we could "allow" direct pushes).

> > In principle, I find it difficult to trust someone who never did a code
> > review in public to have unrestricted commit access to the Noosfero
> > repository. I have no evidence that such someone is capable of detecting
> > basic code problems that I usually find in a relatively large share of
> > the patches that I review.
> >
> What is testing? It is composed of automated tests (runned by the continous
> integration system, travis, gitlab CI) and users' tests, which we at EITA
> and blogoosfero do a lot.
> Reviewing for me is mainly about testing. I don't need pretty beautiful
> code, even after I have wrote
> http://noosfero.org/Development/PatchGuidelines completely for that!

I was not referring to aesthetic issues, and I don't understand what made
you think that I was. A lot of actual problems can be detected by
reading the code. The large majority of the PatchGuidelines topic (which
you didn't write by yourself by the way) is *not* about aesthetics.

Even though, in practical terms a consistent coding style helps
maintainability in practical terms (and checking for it can be automated
so we don't need humans wasting time with it).

> > > About forks, we at EITA can't think of it as a solution.
> >
> > Note that in practice Cirandas is *already* a fork. It is one that is
> > always working towards reducing the delta with regards to Noosfero, so
> > it is a friendly fork that works together with the community.
> >
> > Not all forks are Evil™.
> >
> That is already a fact with Participa and probably many networks in the
> future. And of course we can do much better than that.

Absolutely. I did not point Cirandas specifically to pick on you;
Cirandas was just the example closest to you.

This is also common in other projects, and the effort required to not
diverge from upstream in a unrecoverable way is a real issue.

-- 
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: 819 bytes
Desc: Digital signature
URL: <http://listas.softwarelivre.org/pipermail/noosfero-dev/attachments/20140623/9620d8ec/attachment-0001.pgp>