kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 03/14/2014 05:36 AM, Fabrizio Tappero wrote:
> Hi Kostantin,
> 
> It is my opinion that this is the KiCad developer mailing list and we
> are all here to make stuff for the community and not only for ourself.
> 
> The process is quite easy. You and I can try to work together and find
> a proposal and do some work. Once we are done we propose it to the
> community and they will accept it, refuse it or accept after some
> further modifications. The aim is not to impose your own ideas but
> instead implement what lots of skilful people behind KiCad reckon is
> best to do. There is really nothing difficult about it.
> 
> If you think you can work in this collaborative way let's go ahead if
> you do not think you can let us not go ahead. Please, let's stop
> bugging the mailing list and let's start communicate and work within
> the two of us.
> 
> I am positive that some/many of your icons can contribute to the
> current kicad version.
> 
> Regards
> Fabrizio


Konstantin,

I find it unfortunate that the two of you have spent enormous effort on accomplishing the
same thing.  One wishes for a time machine and better mailing list communications about
what one is going to work on in advance, so that coordinated efforts be constructed so as
to eliminate wasted effort.

I really like and appreciate the icon effort of Fabrizio.  I have not looked at your work
yet, but if Fabrizio says there are some superior icons in there I easily believe that.
And I appreciate your work also.

>From this point, I only see two paths forward.  There may be more, I just don't see more.

1) Cooperate with Fabrizio offline.  By that I mean as co-equals, with the idea that the
fallback path in the event of a cooperative break down is number 2) below.


alternatively:


2) We put your icons in a parallel directory structure in the tree.  This would require
that they all have the *same names*, and that it be a complete set.  Then people can use
yours simply by renaming one or two directories temporarily.  But yours would be in the
source tree.  A person may use yours for a week, then use the others for a week.  A third
directory set would be the result of vote casting, and would initially consist of a copy
of the current set of icons, call this the official directory set.  So there would be 3
directory sets, two copies of current, and yours.  One of the current ones is for voting
results, and is called the official directory set.  (This is only possible if your set is
complete and uses the exact same names, and introduces no code changes or anything else.
If you cannot meet these conditions, this path is not possible and 1) is the only option.)

Path 2) is literally competition.  There is a saying in English that "competition breads
success".  Path 2) will result in good icons for the project.

It is hard to imagine that resources and effort have come forth to the extent that we have
the luxury of allowing competition.  But we must, I think.  We allow it, and Konstantin
gets to choose that path, or gets to choose path 1).  It should be your choice Konstantin,
because Fabrizio already owns the position of status quo.  I hope you choose path 1), but
should offer you path 2) as a fallback or initial path.

I do not weigh as heavily as others, the importance of keeping the user's manual icons in
sync with the software.  It seems impossible to get all users to even look at the user's
manuals.  BTW, I think Fabrizio's work on the user's manuals will go down as one of the
most significant contributions to KiCad of all time, even if it goes without proper
wide-scale appreciation.  (Significant contributions without proper wide-scale
appreciation seem to be a disease associated with open source.)

In any case, I mention the user's manuals so that someone does not put those in the path
of 2) as an obstacle.  This path must be available to Konstantin for this magnitude of
work.  What we see on screen is more important than what we see in the manual.  And the
project must be in the position to benefit from anything which improves it.

If 2) is chosen, how will "voting" occur?  I think in the form of patches coming from
developers, where the content of these patches are individual *.svg and *.cpp files being
copied from Konstantin's directory to the official directory.  Voting would continue for a
limited time, say a year, then stop.  A committer must agree to the icon superiority, that
would entail loading both into Inkscape side by side, and having two build directories
with two executables on screen side by side.  A committer can also cast such a vote
unilaterally.

Again, I hope you chose path 1) initially, but I fully understand if you chose path 2)
initially or subsequently.

Competition is not a bad thing, except to those having to compete.  Competition should be
thought of as a luxury in the eyes of the project as a whole, since it breeds success.

This are my thoughts on how the project can get out of a difficult situation, and are my
recommendations.


HTH,


Dick