<process> Collective ordering of SW standards

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

<process> Collective ordering of SW standards

Craig Carey-2
Rob Lanphier wrote:
>My brain isn't disciplined enough to deal with coming up with brackets
>and symbols and little squirrelly things just to get a subject line.  

I didn't propose putting those things in the subject line.  See my
example message on 3/5/96 on Hitler-Stalin-Middle.  Each argument in
the message is categorized with the keyphrase syntax located just
beneath the argument.  Sticking them in the subject or at the top of
the body will be less useful than placing them with the argument.

I've been putting <process> (and some other variations of it, sorry)
in the subject line as a courtesy to distinguish these administrative
messages from the methods debates.  It's not important.  The subject
lines won't be relevant if keyphrase discipline is applied in the
message bodies.

>I suspect that mailing software is going to get smarter over the
>next year or two, anyway,

I want to deliver the SW and MW election reform reports sooner than
that time frame.

>and that doing full text search on all of your saved messages won't
>be that big of a deal.

A full text search of all the messages will return too much, totally
disorganized, and will break down if we don't standardize our
keyphrases.  The results will have to be read carefully (and reread
and reread upon subsequent searches) to organize the relevant
portions.

>I really don't want to impose a burdensome system to deal with a
>problem that is likely to go away.

It won't go away soon enough.  I don't think it will go away at all
unless we agree to use identical keyphrases, or are willing to
assemble a thesaurus.

>Please, let's not get bogged down with administrivia.

If you make your ideas hard to find when we're in the process of
assembling the report from messages, then why write them?

We have an opportunity to test both two proposals.  We can discuss
one standard without the keyphrase syntax and one with, and write up
those two sections of the report.  If I'm right, then the time we
invest on the discipline will more than pay for itself (principle:
write once, read many), and will give us confidence we didn't
overlook any arguments.  If you're right, we can proceed with less
discipline.

Another principle: the chore of converting messages to readable
report needs to be as simple as possible, to increase the likelihood
that it will get done.

Perhaps there's a middle proposal which will be as effective with
less discipline?  You didn't comment on whether you will have a
problem sticking to commonly accepted keyphrases, which is the most
important element of my proposal.

Even if we were all in consensus to try the keyphrase discipline,
I'll want us to test it by writing up one section of the report at
the earliest opportunity.

>If we must have keywords, though, I suggest that we use the standard
>"Keywords" header that many newsgroups have used for years.

Maybe your suggestion here was based on misunderstanding that I
wasn't talking about the subject line.  If not:

1. Won't work unless we have the software tools to do complex text
searches.

Example:
   keywords:  Majority Rule Plurality Centrism
A search for "plurality" will find all instances, not just the
instances which are near the pattern "keywords:".  At the very least,
we'd have to pass the search result through an additional filter
which can find the nearby pattern "keywords:"

My syntax is a shorthand equivalent to:
   key: Majority Rule key: Plurality key: Centrism
which permits any search engine to locate the Plurality key without
also returning other instances of Plurality.  And if we always place
the standard key in front of the method(s) key(s), we can easily do
tighter searches.

2. We're dealing with phrases, not words.  Isn't a delimiter between
keys useful?

3. We'd still need to agree on a common set of phrases to avoid a
major search headache.  (You could suggest using common phrases with
the "keywords:" syntax.)

4. There won't be a way to see at a glance that two messages are
about the same argument unless the arguments are categorized with
standardized keyphrases.  (You could suggest using the "keywords:"
syntax at the location of the argument instead of at the top of the
message.)

5. There are more keystrokes in "keywords: " than "{{".

I suggested the "{{" shorthand for "keyphrase: " after only a couple
minutes thinking about squirrelly patterns.  It has to be a unique
pattern.  I welcome other ideas: maybe [[ to avoid the shiftkey?

It could be a "beginphrase phrase endphrase" pattern like {phrase},
but {...} doesn't look unique.  {{phrase}} might be unique, but adds
keystrokes.

Rob, if you can come up with something less squirrelly than {{ which
delimits phrases from each other, we can both be happy.

>> We'll have to maintain a list of accepted keyphrases to name the
>> Standards and the Methods, and maybe also the Arguments.  This
>> should be easy to maintain.  We can rotate this secretarial duty
>> among volunteers.  (Don't everyone stand up at once...  :-)
>
>This is your baby.  I've got enough on my hands, thank you. :)

The big question is whether you and others will try to use the
common keyphrases in your messages.  No one will maintain the
keyphrase faq if it isn't useful.

>> Rob has written about hypermail.  Maybe he can suggest how we can
>> structure our messages to take advantage of it.
>
>I don't know of any way to take advantage of keywords in Hypermail.

Do you know of a way to take advantage of other structure, besides
keywords?

--Steve

Reply | Threaded
Open this post in threaded view
|

<process> Collective ordering of SW standards

Craig Carey-2
On Wed, 6 Mar 1996, Steve Eppley wrote:
> Rob Lanphier wrote:
> >My brain isn't disciplined enough to deal with coming up with brackets
> >and symbols and little squirrelly things just to get a subject line.  
>
> I didn't propose putting those things in the subject line.  See my
> example message on 3/5/96 on Hitler-Stalin-Middle.  Each argument in
> the message is categorized with the keyphrase syntax located just
> beneath the argument.  Sticking them in the subject or at the top of
> the body will be less useful than placing them with the argument.

I understand it better now that I see it.  However, I think we would be
far better off following the this procedure:

*  The FAQ maintainer posts an initial draft
*  People submit *specific* changes to that draft to the FAQ (i.e.
   changes that can be cut and pasted into the draft, not general "well,
   you should probably say something about ____")

Everyone who wants to contribute is responsible for making sure their
arguments get into the FAQ.  *Nobody* is going to want to be the FAQ
maintainer if they are responsible for sifting through every piece of
email everyone else wrote.  It'll suck up way too much time of the FAQ
maintainer.

> >Please, let's not get bogged down with administrivia.
>
> If you make your ideas hard to find when we're in the process of
> assembling the report from messages, then why write them?

To flesh out ideas.  Discussion for discussion's sake.  A FAQ is also
good, but I don't want to make this list more work than it's worth.  None
of us are getting paid here.

We need something concrete like a first draft of the FAQ.  I submitted the
CVD FAQ as an example, but in retrospect I think we are better off keeping
that as a basic primer.  It sounds like you have a first draft or outline
or something. *Please* post that, and let us submit our changes to the
list.  If no one on the list objects to the changes, then the FAQ
maintainer should approve them by sticking them in.

Steve, do you want to be the FAQ maintainer?  If we limit the scope of
the job, I think it will be managable.  Let me reiterate the rules for
the rest of us:
*  Only specific FAQ changes will receive serious consideration.
*  Changes must be submitted to the list

If this effort peters out in a week, we'll still have a draft.  That's
better than having a list of keywords.

If we keep a hierarchical, numbered FAQ structure, we can make have a way
of notating context for our changes.

We can also have rotating FAQ maintainer.  I'm all for that.

> Another principle: the chore of converting messages to readable
> report needs to be as simple as possible, to increase the likelihood
> that it will get done.

I think the only way of increasing the likelihood that a report will get
done is doing a report.

> I'll want us to test it by writing up one section of the report at
> the earliest opportunity.

Please, just go for it.  If it is unfairly biased toward Steve Eppley's
point of view, we'll let you know :)

> The big question is whether you and others will try to use the
> common keyphrases in your messages.  No one will maintain the
> keyphrase faq if it isn't useful.

I doubt I will, to be honest.

> Do you know of a way to take advantage of other structure, besides
> keywords?

Here's the docs for Hypermail:
http://www.eit.com/software/hypermail/hypermail.html

I skimmed them and couldn't find anything. YMMV

Rob Lanphier
[hidden email]
http://www.eskimo.com/~robla