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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
