From: Kevin Carhart <kevin@carhart.net>
To: edbrowse-dev@lists.the-brannons.com
Subject: Re: [edbrowse-dev] wikipedia
Date: Mon, 16 Jul 2018 18:44:54 -0700 (PDT) [thread overview]
Message-ID: <alpine.LRH.2.03.1807161818530.15898@carhart.net> (raw)
In-Reply-To: <20180613095834.eklhad@comcast.net>
There's a new remark on the deletion discussion page which makes me think
that they are going to delete the page. They aren't accepting that distro
presence demonstrates that the project extends far outside of the biases
of edbrowse-dev aka us, whose perceptions are clouded by
loooove for edbrowse. I'm not sure why usage itself can't be thought of as something
that applies "show, don't tell" to a FOSS project. Articles document that
something is valuable, while stepping outside of the thing's own medium to
talk about it in prose, and then you have to step back in to use it.
Retrieving something and trying it out because it's FOSS and you can do
this immediately, is a tough, disinterested inline test of whether the
thing has merit which takes place without stepping outside to prose and
then stepping back in. If the library or application isn't good, you're
going to delete it quickly and it will be considered for deletion from the
distro. But I guess this point of view is not going to
get past the Wikipedia consensus process and the arguments that the
members of the deciding committee have been posting for "DELETE", which
they then back up with references to Wikipedia's ground rules. I think if
we have examples of endless inconsistency and other articles that remain
published even though they don't pass a ground rule either, the committee
just says "too bad."
So the second half of this for me at least is that we tried. I'm sorry I
couldn't make it happen through trying to write them something methodical
and clear. If we lose, I don't think it's an important proxy for the
value of the work. It's not an omen. I'm sorry that it has that
discouraging quality to it but don't let it get you down. As KD noticed
while we were working on drafts, hell, duktape doesn't have its own page
and they are thriving. So maybe there are plenty of other venues we can
use instead, such as all of those Stack Overflow answers where someone
says "what are my options for a CLI browser with pretty decent
javascript?" And people say edbrowse since that happens to be true.
next prev parent reply other threads:[~2018-07-17 1:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-13 13:58 [edbrowse-dev] wikipedia, if anybody cares, if it really matters Karl Dahlke
2018-07-17 1:44 ` Kevin Carhart [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-02-14 10:27 [Edbrowse-dev] wikipedia Karl Dahlke
2014-02-14 13:40 ` Chris Brannon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LRH.2.03.1807161818530.15898@carhart.net \
--to=kevin@carhart.net \
--cc=edbrowse-dev@lists.the-brannons.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).