Re: [Pan-users] VDQ Re: Policy discussion: GNKSA

[Duncan]

Beartooth posted on Mon, 04 Jul 2011 21:06:07 +0000 as excerpted:

> It's another tack on the question of theory and practice, applied
> this time to the GNKSA itself. Given that GNKSA is a great idea, to
> which we all wish well; and given also the observations in this thread
> about its currency; I ask -- seriously, wanting to know, *not* snidely
> -- what difference does it make? Not would it make, could it make, nor
> has it made, but as a factor influencing the development and greater
> glory of Pan 0.135+

Far from the "VDQ" you made it out to be, I at least considered this 
question viable enough to re-mark your post unread, and save it to reply 
to later, when I could think about it more clearly.  Here's that reply. 
=:^)

> What will Heinrich, blessed be all his tribe, do differently
> other than backing out that change? Will it snowball somehow?
> 
> What will the effect be on how Pan works, who adopts or emulates
> it, or whatever? (If Pan Triumphant will emulate the horseshoe nail by
> making the whole Evil Empire of Redmond fall into a cybernetic abyss,
> Excelsior! say I.)

You might not be the most tech-headed guy in the world, but you 
definitely know how to come up with impressive quotes! =:^)

(For those who may not know his background, and correct me if I'm wrong 
Beartooth, I don't think I'm revealing anything too private and believe I 
got it right... you're retired from working at the Library of Congress 
for quite some years.  Some of us may be more technical, indeed, but you 
very likely have most or all of us beat by "many podes"[1] in terms of 
well-rounded well-read-ness.)

To answer the question...

I'm not so afraid of what the change to the number of connections by 
itself will do.  That's trivial.  But what I *am* quite afraid of is, as 
you said, the potential snowball.

The requirements of GNKSA have shaped pan quite a bit over the years.

As an example, back I believe during the year of intense activity after 
the release of 0.90 as the initial pan rewrite in C++, there was some 
discussion over toolbar icons.  At the time, pan had three identical 
icons in a row, post to newsgroup, followup to newsgroup, reply by mail, 
and Charles thought that was a bit confusing.  Someone was also trying to 
use pan on a netbook, and pan's minimum window width was too wide due to 
all the icons in the toolbar.

Not thinking about GNKSA, I noted that the composer window has both a 
newsgroups line and a mailto line, and wondered why there couldn't be 
just the single "reply" button (in addition to new-post, of course), 
noting that most often use the followup function (via hotkey) here 
anyway, and delete the newsgroups line content and fill in the mail 
address as necessary.

Charles pointed out the implications GNKSA had in that regard (point #2, 
separate commands for new posts, followup to group, email reply), and 
that a general "reply" button would violate a specific GNKSA SHOULD due 
to vagueness.  Here's the relevant part:

>> Software that uses the English language is strongly encouraged to
>> include the phrases "Post to newsgroup", "Followup to newsgroup",
>> and "Reply by e-mail" (or "Reply to sender" or "Reply to author")
>> -- in menus, on-line help, and written documentation.  It SHOULD
>> avoid using other verbs such as "Send" or "Respond" whose meaning
>> is not evident to the user.  An ordinary, untrained user SHOULD be
>> able to easily pick the correct command.

So a single "reply" button was out of the question.

After a bit of further discussion, Charles decided (after I revised my 
original suggestion accordingly) that followup to newsgroup was what we 
should be encouraging as the default anyway, while reply to poster 
shouldn't need to be used as often, and since we were trying to reduce 
the number of icons on the toolbar and the reply-by-mail menu item (with 
a hotkey by default) would remain it didn't need a button.

Directly, GNKSA prevented pan from making the mistake of having a vague 
reply button.  But in the process of honoring GNKSA, we ended up with a 
stronger pan, because we slightly discouraged replying via mail, while 
slightly encouraging posting to the group, while at the same time 
reducing pan's toolbar icon count by one so the window could be made 
narrower, to fit on smaller screens.

That's a real, concrete example.

As I recently went over the whole GNKSA 19-point list, I was impressed 
again at how basic most of the points are, but how easily they've been 
missed by even popular software.  Take point one, display all essential 
header info.  The details for that point list author, subject, 
newsgroups, followup-to list (if the author set one), and reply-to 
(again, if set).  It also doesn't allow truncating the display (while 
allowing scrolling if necessary) for most of them.  Pan's an established 
app that already handles it "right" so things aren't as critical for it 
as perhaps for newer software for which the GNKSA may be (or may have 
been, in the day...) a guide, but consider what happens if people start 
using pan on phones with say a 40-character narrow display.  Someone may 
decide that truncating the headers and/or omitting, say, author, is a 
good idea.  With GNKSA, pan is free to have an OPTION not to display the 
author header if it wants, but the DEFAULT for that option must be to 
display it.  Similarly, someone may decide that only showing the first 30 
chars of the subject line is fine.  GNKSA would force them to reconsider; 
they could show only 30 chars at a time, but they'd have to have a 
scrollbar if so.  Instead, they may decide to implement a double-line 
subject display, since the scrollbar would take up about the same space 
as a second line anyway.  That'd take more vertical space, but vertical 
scrolling tends to be less hassle than constant horizontal scrolling back 
and forth, so it'd still be a win over a horizontal scrollbar, and a HUGE 
win over simply truncating the subject line so the user couldn't see what 
they needed to see.

That's an example that's rather more theoretical.  The point is, 
programmers have made these sorts of mistakes before, and GNKSA forces 
those who might repeat them to reconsider.

If pan were to stop considering GNKSA something to be followed, it 
wouldn't result in drastic badness overnight.  Rather, over time, changes 
like the above vague reply button, or perhaps truncated critical headers 
on narrow displays, would likely creep in, and pan would be the worse for 
it.  Additionally, if as a result users were more apt to get confused by 
for example the vague wording on a button, and make more mistakes sending 
replies to the wrong place, other users would be irritated, and  pan 
would start to lose its reputation.

That's the sort of problems I fear, should pan decide that GNKSA isn't 
important any longer.  And even if we just overrule it in the one aspect, 
number of connections, that few are trying to defend anyway, it means pan 
loses that seal, and once it has lost that seal, than GNKSA ceases to be 
as important as it once was, and it's easier to try to justify other 
moves away from it, and/or to eventually forget about it entirely, 
something I'd really hate to see happen, because I think ultimately, pan 
will be the worse for it.

Meanwhile, old-pan used to have a hard-coded limit of four connections, 
and Charles would always politely decline suggestions to change it, while 
happily pointing out the line in the source code to change should a user 
wish to do so and recompile pan with whatever limit they wanted.

But users now only have to edit a single xml-text-based config file; they 
no longer have to edit a hard-coded option in pan's sources and recompile.

It's worth noting that I think everyone considers that a good thing.  
Some might even consider that the correct zen balance between making it a 
GUI config option, thus breaking GNKSA, and making it a hard-coded source-
edit-and-recompile option, as it used to be.

And it /does/ seem that the majority of users at least on this list (tho 
I remember well my own claim in a reply to you in a different context, 
that list posters can't be taken to be representative of the pan 
majority, by far), once I asked, appear to prefer keeping pan GNKSA 
compliant, letting those who really want more connections, edit the config 
file to get them, rather than losing pan's 100% GNKSA seal.

Still, as I've posted several times, if there's one thing I'd change 
about GNKSA, it's this four connections thing, which I believe was 
anachronistic even when first introduced.  If we can take the opportunity 
to appropriately modernize GNKSA in this regard and perhaps tweak a 
couple other points here or there as considered appropriate, I believe 
everybody concerned would consider that the best possible alternative.

Will it happen?  It's a bit early to say, but a GNKSA change surely looks 
more likely now than it did before I brought the whole subject up.

> And how will the GNKSA, ossified or not, and New Pan's take on
> the GNKSA, affect things like the prestige of Gmane?
> 
> That matters. To take one small example, I try to monitor two
> very busy lists which the likes of me could follow far better were they
> only here. If limiting Pan, or de-limiting Pan, or spelling it backward,
> will affect those lists' willingness to join Gmane, I'll vote
> enthusiastically for whichever one does it.
> 
> So will a lot of the Baby Boomers now entering retirement, unless
> I miss my guess; they've been treading on my heels since hector was a
> pup.

FWIW, I believe pan really plays a very small part in gmane and its 
reputation.  The reluctance of certain list admins to making their lists 
available on gmane is, I believe, more related to gmane's web interface 
and in any case almost CERTAINLY more related to their concern about spam, 
than to anything pan might do or not do.  I'd attribute /most/ of it to a 
lack of understanding of how the gmane mail address obfuscation feature 
works -- if indeed they are even aware of it.  And simply telling them 
about it isn't likely to help in most cases, unfortunately, because 
they've already made up their minds without properly informing themselves 
of the spam-fighting option gmane already has.  Meanwhile, even on the 
news side, I'd bet that gmane still likely has way more OE users (and 
thunderbird users too) than pan users.  And of course the "real" gmane 
folks tend to all use emacs and gnews/gnus/equivilent, not to mention all 
the other news clients around.

Plus, if spammers are going to use gmane's news interface to try to 
harvest addresses, they're not going to be using pan to do it, but 
rather, some automated script.

So indeed, as a gmane user myself, I certainly share your concern about 
it, but really, whatever role pan may play in gmane's general reputation 
and acceptance is going to be relatively trivial.


Hopefully that answers your question with some clarity.  Of course, it's 
my opinion, but in all humbleness, I suppose that counts for /something/ 
around here.  At least as much as any other "joe poster" opinion might 
count. =:^)

(Actually, it's a bit scary to think about, but in a way, it's very 
possible by being the consistent regular in this group/list that I have 
been, I kept it alive enough to keep khaley and now get hmueller 
interested in pan code.  khaley and I apparently both started posting to 
the list within about a month of each other, back in 2002 (looks like 
khaley beat me by a month, started in Sept, while I started in Oct, based 
on gmane's list archive), and we've both been around since, tho it looks 
like he took a vacation for 2007, and only posted twice in 2005.  
However, you'd have to ask him if without me, he'd have considered the 
list, and therefore pan, dead, and whether he would have been inspired to 
start developing for it again, or not.  Certainly I believe it's 
reasonable to say that had I given up on pan in those dark days, even if 
it was still around today, the list and pan itself wouldn't be anything 
like the lively community we have today.  And I came close... I did 
indeed come close.  So I guess I can say I've changed history in at least 
that way.)

---
Footnote:

[1] "many podes":  See http://en.wikipedia.org/wiki/Pous

Podes is plural of pous.  Pous is an ancient unit of length similar to a 
US foot, used by the Greeks.  (Related terms, podiatrist, quadriped and 
pedal, all relating to feet.) There were 600 "podes" in a "stadion", the 
plural of which is "stadia", from which comes our word stadium.  Thus, 
the analogy was to an ancient Greek foot-race.  FWIW, I was originally 
going to use the term "stadia" in place of miles, but decided I better 
wiki it first, especially after the spellchecker flagged it.  When I did, 
then followed thru with its reference to podes, I ultimately decided 
"podes" and with it the implication of a foot-race which he won by quite 
a distance, was far closer to what I wanted.  I quite expect he got the 
implied reference without all this explanation, tho I certainly wouldn't 
have, nor would I have even had a clue what "podes" were, before looking 
all this up, at least.  I learned something new today, and now, I expect, 
have many of you, likely other than Bear, of course, for whom I expect 
the reference was very possibly almost natural! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman