Developers of Sympa

[IKEDA Soji <address@concealed>]

Hi all,

I apologize beforehand for slightly long post.

On Mon, 03 Mar 2014 17:47:51 +0100
Guillaume Rousse <address@concealed> wrote:

> Le 03/03/2014 17:10, IKEDA Soji a écrit :
> > Hi,
> >
> > On Mon, 03 Mar 2014 17:01:40 +0100
> > Guillaume Rousse <address@concealed> wrote:
> >
> >> Le 03/03/2014 16:49, IKEDA Soji a écrit :
> >>>>>      May use English names along with non-English names, however, if
> >>>>>      multiple English names are given, only shortest one may be used.
> >>>>>
> >>>>>      e.g. $! and $ERRNO may be used but not $OS_ERROR.
> >>>>>        Anyone shouldn't blame use of $ERRNO and others shouldn't blame
> >>>>>        use of $!.
> >>>> I disagree: why should we allow both forms to coexist ? What would we 
> >>>> gain ?
> >>>
> >>> I ask myself, "Is anyone can feel unreasonable to use English
> >>> names?".  My deep psyche answers: "Someones prefer to $$ and others
> >>> prefer to $PID.  They are havng unfinished struggles on the Net and
> >>> real world even today".  So I proposed this issue not to be unfinised.
> >> You're still not answering my question: what would *we* gain by letting
> >> this kind of inconsistency subsist in the code *we* have to maintain ?
> >>
> >> Basically, I just don't care about what the rest of the world think of
> >> '$!' vs '$ERRNO', and other similar cosmetic issue. I just do care about
> >> the preferences of people currently involved in Sympa. And my own
> >> preference goes toward enforcing overall consistency, for better
> >> readability first, for easier refactoring second.
> >
> > We including you may normalize system variables to English
> > forms.  However, such policy wouldn't be enforced on any contributors
> > nor any future developers.  Such I proposed.
> OK, sorry for my mistake.
> 
> But even if someone submited code with $OS_ERROR, we could also 
> normalize it thereafter. And that's also true for indentation issues, 
> etc... So what's the point of discussing what we are ready to accept, 
> and what we are not ? Do we really have so much incoming contributions 
> than we need to sort them out ?

I suppose that the purpose of our discussion on this list is not
only to reach agreement with us.  The consensus we have reached
should be shared by (present and future) contributors.  In short,
our ultimate goal is to publish some sort of "guidelines".

And this is the point: The guidelines are not like the law.

- They are not rulebooks but they consist of several number of
  "good practices".

- They never will punish anyone who doesn't respect them, but
  they only present recommended practices.

- They may often not be comprehensive, and even may sometimes be
  inconsistent from wider point of view.

Consequently, we don't necessarily need presenting only one option
by each issue.  Option can have fluctuation.

However, guidelines should also be logical.  Because they cannot
enforce themselves by penalties but by persuations.


I wrote:
> > I feel nice to use English names for rarely used variables.
> > However, what means "rarely used" may be differ from one another.

So I proposed that usage or non-usage of English names will be
optional.
But unlimited usage of English synonyms seemed not desirable.
So I added "shorter names" terms to my proposal.

To do it, I took care that my proposal can be logical, i.e. it can
cover all over the target of this issue, system variables.


> Personaly, I've been enough rebuffed having my own documentation patches 
> refused because of a few typos to avoid repeating the same errors with 
> other people :)

Though I don't know about things on that, the committer probably
wanted to save her/his time.
Of course s/he may be able to correct typos, but they are not
obliged to do it.

Or, even if a guideline of such project recommended to perform
spell check everytime before submitting patches, it will not always
be respected.


On reflection, as a committer of Sympa project, we may or may not
reject some contributions because of not respecting some sort of
guideline.

Note that such behaviour has _no connection_ to guidelines but is
due to free will by each of us.

(Turning around) If you rejected your patch by one committer, you
can try sending it to another. ;)


Regards,

--- Soji


-- 
株式会社 コンバージョン  セキュリティ&OSSソリューション部   池田荘児
〒231-0004　神奈川県横浜市中区元浜町3-21-2 ヘリオス関内ビル7F
e-mail address@concealed  TEL 045-640-3550
http://www.conversion.co.jp/