always assume good faith

Mon Jun 23 15:30:26 BRT 2014

On Mon, Jun 23, 2014 at 1:20 PM, Antonio Terceiro <terceiro at colivre.coop.br>
wrote:

> 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.

The main benefit of adding commiters from Noosfero's networks is to bring
them togheter and letting them do the investment on the platform,
independently of one central point. The will *potencially* make
participation more interesting to bring functionalities and share costs
between developers from organizations, as they can take decisions directly
with other actors, instead of asking if something is good to one group of
developers. Currently in Noosfero, we have that logic of "code moderators",
because the cost of maintenance is due to one actor, so it has to moderate
requests according to its resources and interest.

This is what happens in other softwares, which in terms of line of code
maybe be even smaller than Noosfero. I don't know for sure, but Wordpress
is probably smaller than Noosfero considering lines of code, but it has
more than 50 commiters (information from a friend from Hacklab)!

>
> 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).
>
Yeah, that is the extreme case we of course don't want. The "wants" maybe
be discussed, to set limits on what people can do and should behave. I like
this proposal you gave of 1 commit -> >0 reviews.

The commiters don't need to have all the same role [1], and some planning
for directions (e.g. roadmap) and cooperated coordination between commiters
is always needed, and between commiters and non-committers, as you probably
know well from many free softwares. There are many different dynamics in
free software. Wordpress uses one, Linux another, etc. Wordpress, for
example, has a concept of "top contributors" which may look to something
and question or change it.

The thing is, we cannot go from the extreme we are (centralization and high
cost for one organization) to the extreme descentralization. Of course,
extreme descentralization is not what I'm proposing, and somehow I think
that's what you are perceiving.

[1] Wordpress example:
The WordPress Core Team #
<http://make.wordpress.org/core/handbook/project-organization/#the-wordpress-core-team>

The WordPress project is led by the *core leadership team*, which consists
of WordPress co-founder Matt Mullenweg, five lead developers, and six core
developers with permanent commit access.

The lead developers are *Ryan Boren*, *Mark Jaquith*, *Andrew Nacin*, *Andrew
Ozz*, and *Peter Westwood*. These developers have final authority on
technical decisions, and lead architecture discussions and implementation
efforts.

*Sergey Biryukov*, *Jon Cave*, *Helen Hou-Sandi*, *Dion Hulse*, *Daryl
Koopersmith*, and *Dominik Schilling* are permanent core committers.

Top ↑ <http://make.wordpress.org/core/handbook/project-organization/#top>
 Contributing Developers #
<http://make.wordpress.org/core/handbook/project-organization/#contributing-developers>

WordPress has a number of *contributing developers*. Some of these are
former or current committers, and some are likely future committers.
Regardless, these are trusted and veteran contributors to WordPress core
who have earned a great deal of respect among their peers.

As needed, WordPress also has *guest committers*, individuals who are
granted commit access, sometimes for a specific component, on a temporary
or trial basis. *John Blackbourn*, *Drew Jaynes*, and *Scott Taylor* are
currently guest committers.

Other contributing developers include *Michael Adams*, *Nikolay
Bachiyski*, *Mike
Schroder*, *Joseph Scott*, *Andy Skelton*, *Matt Thomas*, *Lance Willett*,
and *Samuel Wood*.

http://make.wordpress.org/core/handbook/project-organization/

> > > 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).
>
Agree. I touched this point because I don't like when developers try to
impose their coding style or the exact way and place of doing something.
That's part of the sense of property developers have upon their code, and
that sense usually harms more than helps the code to evolve.
If the final user is benefited and the code doesn't break others' code,
than it is OK to have 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/
>
>
>
> _______________________________________________
> Noosfero-dev mailing list
> Noosfero-dev at listas.softwarelivre.org
> http://listas.softwarelivre.org/cgi-bin/mailman/listinfo/noosfero-dev
>
>

-- 
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
http://cirandas.net/brauliobo
http://eita.org.br

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é meu
lar e todos nós somos cidadãos deste cosmo. Este universo é a imaginação da
Mente Macrocósmica, e todas as entidades estão sendo criadas, preservadas e
destruídas nas fases de extroversão e introversão do fluxo imaginativo
cósmico. No âmbito pessoal, quando uma pessoa imagina algo em sua mente,
naquele momento, essa pessoa é a única proprietária daquilo que ela
imagina, e ninguém mais. Quando um ser humano criado mentalmente caminha
por um milharal também imaginado, a pessoa imaginada não é a propriedade
desse milharal, pois ele pertence ao indivíduo que o está imaginando. Este
universo foi criado na imaginação de Brahma, a Entidade Suprema, por isso
a propriedade deste universo é de Brahma, e não dos microcosmos que também
foram criados pela imaginação de Brahma. Nenhuma propriedade deste mundo,
mutável ou imutável, pertence a um indivíduo em particular; tudo é o
patrimônio comum de todos."
Restante do texto em
http://cirandas.net/brauliobo/blog/a-problematica-de-hoje-em-dia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.softwarelivre.org/pipermail/noosfero-dev/attachments/20140623/4ffb925c/attachment-0001.html>