[consulting] Drupal Primer Course

[Lists]

"Greg Knaddison - GVS" wrote:

>> Is this the general
>> tendency with Drupal?
> 
> I would say it's just the tendency with software.  If you disagree I'd love to
> hear examples of companies that /don't/ motivate people to upgrade.

I think you may have jimmied the meaning, or context, of my comment.

Certainly upgrading is prudent for users (to gain new features and
improvements) and it's prudent for developers (to limit support branches, as
you say.)

But...encouraging upgrading to a system that isn't finished is not prudent,
for anyone.  Why?

    For developers...

    Attention is diverted for actually getting a working stable release by
fending off "bug reports" and "feature requests" on a system that isn't
finished.

    For users...

    There is no stability or guaranteed path in un-finished releases, there
is no joy in creating temporary work-arounds that will be un-work-aroundable
in a few weeks...or not.


>> Is someone actually at the wheel, following a road
>> map?
> 
> The top down view:
> http://drupal.org/node/46638
> 
> But as Dries says in that document: "Code is contributed, or it is not."  You
> can't really set a roadmap and then expect volunteers to follow it.

Sure you can.  Volunteers are not autonomous workers who may do what they
like.  Volunteers are invited guests to any organization and they must
comply with whatever strictures are in place.

You set goals and milestones, you limit distraction, and you move inchingly
forward toward those goals.  Those who do not support the goals are not
given license to divert the goals.


As a way to summarize my single mild criticism of my eight months in
Drupal-land, I would put it this way:

    Drupal seeks to aid non-profit and community organizations, but it does
not exhibit a top-down understanding of the real-world conditions of such
organizations.

    To wit:

    a) the Drupal tech community (lists, posts, etc.) presume a
resource-rich environment and build for, and recommend only, that. [1]

    b) the Drupal site is represents a model of inefficiency at
communicating documentation and help materials [2]

    c) the Drupal tech community (lists, primarily here), as I have
moderately observed, is very quick to suggest that "living in the code" is a
nice place to live, and that everyone should be comfortable in that
neighborhood [3]


So, with only these non-accusatory observations under my belt, how do I see
this as being in conflict with a real world view of non-profits and
community organizations?  (Or, what are those footnotes up there?)

Firstly, and generally, there are significant language problems that
exacerbate the problems of discussing and implementing Drupal.

One of these, and I think the most significant, is the co-opting of the
phrase "community development".  This is a rich field of study and practical
work, and it does _not_ mean "online community site making".

That confusion factor suggests that there is a disconnect between
understanding what it might take to build "an interactive online communal
site" and what it means to be actively involved in the world of physical
community organizations.

    [1] That is, real organizations, with offices and workers and volunteers
and paperwork and grants and so on, have real limits on their resources --
something that __software__ based ideas about "community web sites" are free
to ignore.)

    [2] Open, "wiki-like" editing is a great democratic leveling tool, but
it tends to create a jumbled assortment of "info objects", which are
difficult to evaluate without context.  A software manual has an innate
authority.  A mass of un-connected, scattered "pages" of text, offered by
any number of anonymous users, does not benefit from such an innate
authority.

    The result is frustration and resource-expenditure (time, online
charges, etc.) for organizations which are, already, at their
resource-limits.

    [3] Being a geek-centered tool is fine.  I like that sort of thing
myself, but it's not my daily work.  So, if someone tells me "oh, you will
have to re-write so and so module", then that's a problem for daily work,
even while being a fun exercise at home.

    What would be more helpful, to resource-limited groups, is to have a
manual which says "You can not do this in this version. But, you can
customize so-and-so feature if you have the programming skills and
resources."


Let me say:  I love Drupal.

I think it is, for me, one of the best "finds" of the past year.  I have
already, in just a few months, assisted groups in setting up Drupal for
themselves; given a presentation overview of Drupal for local non-profit
groups; and helped one group write a grant (successful) to get their own web
server to devote to Drupal.

Okay, that's good. And I am happy to have helped. (And will continue.)

But, where I really think that Drupal needs shaking up is in the
"philosophy" (if you will) of understanding such groups, and in helping them
with their resource allocation and respecting their resource allocation.

The goal should be the "The Simplest Most Powerful Tool", not "The Most
Complex and Gigantic Powerful Tool".  The goals are not at odds. Drupal can
continue to offer dazzling innovation, ease-of-use and complexity all while
setting a standard that organizational resources are considered, with
respect to development and documentation.

User frustration, from feedback I've received, is __not__ in the software.
It's in finding help with the software; wading through the variety of
methods of achieving the same goal; and in the amount of time needed just to
assemble a personal set of bookmarks which constitute "the manual".


All of these things are okay, by the way.  Every great project has the same
kinds of problems.  The difference is in acknowledging said problems and
then setting reachable, reasonable goals toward their solution.

For my part, if it's not PHP code that I contribute, then perhaps it could
somehow be related to the documentation issue. <shrug>


I do appreciate the chance to (try to) articulate some of these ideas. A
task at which I may have failed, of course.  And I struggle to articulate
these ideas __because__ I love using Drupal, and not because I do not.

Cheers,
--
Gary