Re: gEDA-user: reasons for wikibook (was: plugins)

[DJ Delorie <dj@xxxxxxxxxxx>]

> a) IMHO, it is good practice to have a user manual completely separate 
> from documentation of features, formats and APIs. While the latter has 
> to be complete, comprehensive and super correct, the former should 
> focus on ease of use. These are conflicting goals. Think automatic 
> extraction from the source versus  

See http://www.delorie.com/pcb/docs/ for my preferred breakdown of the
PCB docs.  I think this matches what you're suggesting.

> e) The entry barrier is as low as it can get. If general readers 
> spot a glitch, they can press the edit button correct the error and
> are done. This provides a opportunity to foster participation of more
> users. Compare this to the circumstances inside the geda project.
> You need to send an email to an admin to even see the edit buttons in 
> the gpleda-wiki. Changes to the pcb manual require git patches and 
> an approval by core devs like changes to the code in git-head.
>
> f) The geda devs have no more say in what goes in a wiki book, than 
> any other user.

While I appreciate the desire to streamline the editing process, I see
two problems with your approach:

1. The easier it is to contribute, the more likely you are to be
   vandalized.  Wikipedia has seen plenty of this problem.  You need
   some method of authorizing trusted contributors and approving
   changes by others.

2. You should not choose a solution based on alienating the
   developers.  They're your greatest source of information on how the
   tools work.  Note: I'm not complaining about your choice, just your
   reasons.

> Given the consistent tendency toward more wall-in over the years, 

We've been adding more people with commit access over the years.  I
don't see this "consistent tendency" you speak of.

> I don't expect this attitude to change anytime soon.

From my point of view as an admin, I see a few users who wish to be
contributors but have a "you must do it my way" attitude.  It is
difficult to accept contributions from such individuals because any
requests for changes to better align with the goals of the project are
met with harsh rebuttals and personal attacks (like this one).  For
such contributors, it is far easier to "just say no" than to try to
work with them.  Compare with other contributors who are willing to
compromise, deferring to the admins until they understand what's going
on, and are granted priviledges and responsibilities within the
project.

In general, if a contributor sees "an attitude" in a project, it is
their reponsibility to adjust their attitude to match the existing
group, not the group's responsibility to match each new member's
individual attitude.  This is not specific to gEDA, I've seen this in
every project I've contributed to.


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user