buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Spiewak <djspie...@gmail.com>
Subject Re: Quick Start Documentation
Date Wed, 15 Jul 2009 21:29:08 GMT
> For users that already have installed buildr and really want to get
> started I think this is not really necessary (unless we find an example
> that's so obvious that everybody needs _this_ custom task to get
> started, what I currently can't think of). Instead, the new user has to
> read more stuff, and the quick start is getting even longer (1/4 or 1/2
> of a screen?).
>
> For potential new users that just stumbled over buildr and want to see
> what it does this is IMHO more interesting, as it shows how easy it is
> to realize a custom requirement like "count loc" or "initialize the db
> schema". So it's more one part of getting a quick overview over buildr
> and _all_ things buildr can do (not only the absolutely necessary).


Ok, how about this for a compromise.  We keep the bit about the :run task,
but we remove all of the stuff about working with custom dependencies.  I'll
replace that with just _(:target, :classes) and we'll leave it at that.  I
think that a :run task is common enough that people are going to want to see
it.  Anything more commonly used would probably be included in the Buildr
core, while anything less would just be uninteresting.


> For both users that want to get their first project up and running and
> those potential-new-users I'd prefer to just mention it and link to a
> page with more information. Basically I think the quick start should
> just mention what's definitely required and link to everything else.


There's a duality to most quick starts, I think.  We need to just give the
basics of what you need to get running, but we also need to highlight the
most fundamental aspects of using Buildr.  I wanted the guide to be a bit
more than a "first thirty seconds of Buildr" overview.

As for the length, I agree with you there.  Maybe we could trim down some of
the wording a bit.  I usually tend towards excessive verbosity in my
extended pontification and overstated verbiage.   :-)

Daniel

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message