Subject: [Tools-team] Re: Contacting the Secretariat

From: Alex Rousskov <[email-masked]>
Date: Sun, 12 Sep 2004 22:39:18 -0600 (MDT)

Hi,

 	I tried to draft our reaction to the Secretariat's "current 
efforts to update its contact information on the IETF Web site" (as 
detailed in Barbara's forwarded e-mails). This is my personal opinion 
and this is just an initial sketch. This is not TOOLs team reaction 
yet, and it may never become one! If there are suggestions to use a 
different format for our response or even a completely different set 
of recommendations, I am all ears.

 	Could TOOLs team members review and contribute, so that we can 
send a decent respond to the Secretariat and IESG?

Thank you,

Alex.

--- Review of proposed changes to Secretariat Requests interface ---

Disclaimer: The TOOLs team does not have complete information about 
the problems discussed in Secretariat-IESG e-mail exchanges. Our lack 
of details, context, and stats may have resulted in wrong observations 
and advice.

This review contains a "general observations" rant followed by 
specific problem analysis and recommendations.

General observation: While cleaning up aliases is useful, we would 
recommend to look at changing the primary interface instead. An 
informal e-mail interface is incapable of efficiently handling large 
volumes of diverse queries and non-queries. An appropriate web 
interface should be used instead, with e-mail left for exceptional 
situations.

E-mail query/response interface gives virtually unlimited freedom (and 
no instructions) to the query submitter and places all the burden of 
deciphering submitter's intent on Secretariat. A web interface that 
let's submitter classify her own request, with immediate 
context-sensitive instructions and feedback is much more efficient. A 
web interface also makes it easy to monitor the status of the 
submitted query.

An informal e-mail interface should be left to exceptional situations 
only. It may have just one alias, protected by a "request 
confirmation" admission control scheme to eliminate spam and 
non-requests (see below for more details on that). It should be made 
clear to all users of e-mail interface that e-mail is discouraged and 
that their query will usually have lower priority that queries 
submitted on the web.

Specifics: Specific problems and suggestions are discussed below, in 
no particular order. We did our best to isolate the problems that 
Secretariat is trying to solve, but since they were not clearly 
identified in the Secretariat e-mails, we may have missed or 
misunderstood a few. Please correct us as necessary.

1) Problem: users mis-categorize requests by using wrong aliases
             users are frustrated because they cannot pick an alias
    Secretariat solution: change aliases names to more intuitive names

Analysis: The solution is likely to have marginal effect due to user 
diversity and natural language limitation (general terms used for 
alias names cannot reliably distinguish related categories).

TOOLs suggestions: Do not rely on alias names to mean the same request 
category to most IETFers. Other interface aspects should maximize 
correct category choice. For example, a web page created for 
submission of requests can force user to select a category and then 
explain the details of the category selected. Mistaken users can then 
back off and re-categorize their request. E-mail requests must be 
confirmed to become active and request for confirmation may include 
explanation of the alias being used.

2) Problem: takes too long to re-categorize mis-categorized requests
    Secretariat solution: minimize mis-categorized requests

Analysis: minimization of mis-categorized requests is the right 
approach, but it is possible that more can be done.

TOOLs suggestions: In addition to reducing the number of 
mis-categorized requests, use back-end that makes it trivial to change 
the category and that informs affected parties of the changes. It 
should not take more that a couple of mouse clicks for Secretariat to 
re-categorize a mis-filed request.

3) Problem: Users left in the dark w.r.t. current request status
    Secretariat solution: n/a

TOOLs suggestions: for each accepted (queued) request, respond with a 
"ticket number" and a user-accessible URL where ticket status and 
queue length/progress can be viewed. The ticket number can be used as 
password to protect sensitive information if needed.

4) Problem: Spam and non-requests entering request queues
    Secretariat solution: intuitive, non-queued aliases to reduce
                          non-requests

Analysis: Spammers will eventually spam all public e-mail addresses. 
If any such address is directly attached to the request queue, spam 
will enter that queue. Humans will continue to CC wrong aliases, 
causing non-requests to be queued.

TOOLs suggestions: Both spam and legitimate non-requests can be 
eliminated with a simple admission control scheme. The scheme would 
explicitly ask the submitter to confirm received request via e-mail or 
web. Confirmed requests will be queued. Other requests will be dropped 
with no further actions. It usually takes about a minute to complete 
the request with these admission controls in place -- a negligible 
expense (on the part of requester) in both absolute and relative 
terms.

5) Problem: Individual mailboxes is a poor mechanism to manage
             user requests for many obvious reasons
    Secretariat solution: automatically forward most requests (based
                          on request alias) to RT

Analysis: This sounds like the right thing to do and, if good 
admission controls are in place, should be very effective.

6) Problem: Lack of request categorization
    Secretariat solution: add more categories (RT queues)

Analysis: This sounds like the right thing to do, provided the user 
interface makes it easy for the user to pick the right category and 
double check their selection before activating the request (e-mail 
interface cannot do the former).

TOOLs suggestions: investigate whether some common requests may have 
overlapping categories. For example, can a "WG action" or an "IESG 
action" also require some technical troubleshooting relevant to 
tech-support category. Can a "WG action" involve IESG? How will the 
user and Secretariat interfaces handle such overlaps?

7) Problem: Duplicate aliases
    Secretariat solution: remove duplicated aliases

Analysis: Cleanup is good, but Secretariat efficiency is unlikely to 
be significantly improved just because there are fewer aliases to 
handle. In other words, this should be done, but duplicate aliases do 
not affect the bottleneck and their removal should not be a 
top-priority item.

_______________________________________________
Tools-team mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-team

---

From: Larry Masinter <[email-masked]>
Date: Sun, 12 Sep 2004 22:18:03 -0700

I think the proper approach is to actually analyze the workflows
and diagram them before trying to evaluate individual local
optimizations.

I'm reluctant to endorse any of these suggestions as "the right
thing to do".

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 13 Sep 2004 10:36:07 +0200

Alex,

I totally disagree with your main assertion that "email contact should be 
left for exceptional situations".

It effectively stops people from getting work done (as opposed to prepared) 
while they are off-net. And while connectivity has improved considerably 
over the last few years, I think this is an inappropriate change.

The cost of appropriately classifying an emailed request is (I think) on 
the order of seconds to minutes - with average probably less than a minute 
(for "ordinary" requests), albeit with a LONG tail for badly formed 
requests. This cost is centralized at the secretariat.

The cost of being unable to finish tasks while not connected is distributed 
throughout the organization.

And don't forget the cost of frustration while trying to express a 
reasonable request through a Web interface; my experience with "web ticket 
submission systems" in non-IETF contexts is that they at times seem 
indented to maximize frustration....

That said, I approve of Web systems for "self service" operation - but in 
the cases where a human will have to evaluate your request anyway, I think 
Web interfaces are more than a little overrated.

                          Harald

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 13 Sep 2004 10:40:07 +0200

Note on the tools team responding:

I explicitly asked Barbara to send you this note for information, NOT for 
action. I want the tools team to maximize its understanding of what the 
secretariat does and how it does it - I do NOT want the tools team to 
approve, disapprove or attempt to modify the changes that are suggested at 
this juncture.

So - do NOT have the team respond on the message, but incorporate the 
information into the "higher level understanding" picture.

                   Harald