Re: [Gnu-arch-users] Re: newbies should neither be seen nor heard

[Zenaan Harkness]

>     Peter> you were mistaken when you wrote that paragraph. Although I
>     Peter> got used to them I still don't like them. They're still a
>     Peter> PITA everytime I want to edit {arch}/=tagging-method.
> 
> Yeah, it can be a PITA.  I haven't fixed my bash or zsh because I
> mostly name files to edit in XEmacs[1] which only has electric
> behavior on '~' and '/' (characters which even Tom wouldn't touch, I
> daresay), so when I do need to use those names from the shell, I get
> surprised.

There is actually a pretty good argument for keeping a high barrier to
entry, particularly in the early days of the development (ie.
prototyping) of new software - it ensures that only those who can
provide quality feedback, and/ or contribute, and/ or are willing to
endure the 'workaround learning curve' will participate ... thereby
freeing up the list and the developers to get on with the most important
job of getting the damn thing working.

The argument _for_ such a barrier to entry is inversely proportional to
the maturity of the project (unless the developers actually want to
maintain a long term elite clique status). Assuming they don't, at some
point on some curve, barriers to entry merely hinder adoption rather
than filter worthy contributors.

> But I've discovered that I like the convention, although I use a
> smaller set of characters.  In particular, I've found leading "=" and
> {name} to be useless, but I use leading '+' for "precious" (ie,
> somehow extraneous to the containing directory but not junk, such as
> personal notes on bugs and RFEs of other people's software) and
> leading ',' for "junk" files in all kinds of contexts now, and the
> sort-by-usage property is useful pretty much every day.

Such technical arguments are useful. Eg. if there is no particular
use (besides directory listing sort order, which could be managed
by context-aware front ends anyway) for {files}, then the techical
argumet for changing these to .gnuarch or similar may be the
stronger argument.

Bring in conflicts with SAMBA/windows, etc, and the argument
becomes even stronger (we need that comparison table now...).

Eg 2, the {archives} directory seems to be almost entirely a
local site-specific policy issue. In which case, the tutorial
should be changed to reflect this (thus lowering one more
barrier to entry).

cheers
zen