This item is for the discussion of newuser.  What should it ask people for?
The following are pretty much required:

1) Login name.
2) "Real" name (they don't have to put in an actual name, but we need
   something for the GECOS field in the password file)
3) Email address (so we can email them their password).

Right now, it asks for some other stuff and uses that to build the user's
.plan file: phone number, address, the type of computer you use, what you
do for a living, gender, birthdate, and what other interests you have.
None of this is necessary.

Actually, for legal reasons, we may *have* to ask for birthdate, but I'm
not a lawyer and not sure.  But I remember that that was a thing a few
years back.

What else?

85 responses total.

Michigan nonprofit corporate law has no reqirement of members' 
birthdates being recorded.

At one point, there was a federal law requiring online services to ask for
users' birthdates, and if they were below 13 years old, verify that their
parents had given them permissions to get accounts.  We just sort of punted
on that.

It has nothing to do with membership.

I'd like to see the web newuser be as simple as needed to set up a
working Unix account (username, password, "real" name, optional contact
information) that will allow web access, so that people can get an
account and get cracking without a lot of technical/confusing questions.
That web new user page should ideally fit on one normal screen.  As long
as they only access Grex from the web, they should be okay and if we add
a few more web services they'll be even better off.

For the command line newuser, my assumption would be most people who
run that will expect it to be on the technical side.  I'm sure it got
as complicated as it did due to all the issues new users had in days of
yore with terminal types, backspace key assignments, etc.  That said,
I'm guessing there is an opportunity to simplify that program/process as
well(?)

Some people will want to register via the web and then use both command
line and web tools.  In that case, we'll need to provide additional
assistance if things like their terminal and backspace aren't working.
Perhaps a script they could run (and a web page they could access) to
update their account settings would be a good idea to save staff time
(change shell, change "real" name, change backspace key assignment,
change password, etc.).

We do want people to learn about Unix, too, so technical questions would
be one of the hoops they need to jump through to get a useful command
line account.  But we don't want it to be an onerous process nor do we
want it to be a dead end.

It would be good information for us to know how users got their
accounts, via the web or via the command line newuser program.  That way
we could judge the popularity of each method and perhaps see a little of
how our user base is changing (if it is).

I wouldn't expect anyone to be any more or less technical based on
how they create their account.  Most services these days, even other
public access Unix services, only provide a web interface for account
creation.  People are so used to it that it would be weird if they
didn't expect it; even most techno-dweebs would login to Grex's
newuser and sort of shrug and say, "oh wow; well, ok...."

I think one of the realities is that we don't need to bother with
backspace keys and terminal types and all the rest of that garbage.
For the most part, that's handled by whatever terminal emulator the
user uses, and whatever SSH clients are out there.  Having us write
software to try and figure it out is probably just going to screw
people up.  Gone are the days when someone only used one terminal,
and that terminal was a VT100 or Wyse 50 or Heathkit 19, and setting
these variables just complicates life for everyone; it's far better
to just run tset and have it do the right thing.

One thing I think is critical is that we should not make a big
distinction between "web" accounts and "command line" accounts.
When a user creates an account on Grex, regardless of whether they
use the command line newuser login or a web interface, they'll get
one account and it will be set up exactly the same.  As I said in
the last paragraph, we don't need to ask about terminal types or
erase and kill characters and junk like that.  For that matter, we
don't need to ask about shells or editors or any of the rest of
that sort of thing: give reasonable defaults and a way to change
and let users do what they want.

So yeah.  Basically, minimalism in the account creation process
seems to be a universally agreed upon good thing.

So what "optional" information should we request?

The reason I was thinking information on how they got their account
was good is that we don't get enough information about how the system
is being used (including how people are finding Grex and getting their
accounts).  We're often making decisions based on annecdotal evidence.
I'd like to avoid that, if possible.

It would be good, at least, to have the "registered" information like we
used to:

registered: Fri Jul 19 16:00:39 1991 on tty /dev/tty01 at speed 2400

Maybe we could add "www" or "command line" to that if it's not obvious
due to the tty.  This information comes from the .plan file, though,
and not a gecos field, as far as I know.

If we can get this information without messing with newuser, then that's
fine, too.

re 2:  I think the law Dan was thinking about is the Children's Online
Privacy Protection Act.

http://www.ftc.gov/ogc/coppa1.htm

resp:5 Newuser already tracks that sort of information and puts it 
into the .plan file; it's just that all the recent users have decided 
to keep their information hidden.  So the registered information is 
there, but private.

Similarly, that information is also logged into a file 
(/var/log/newuser.log).  General users can't read that file for 
obvious reasons.  New newuser logs the data in JSON format, which is 
easy for tools to parse and manipulate.  So we can write programs that 
suck in the newuser log data and do all sorts of statistical analyses 
on them; I agree that more of that and less anecdotal evidence is 
generally a good thing.

Changing newuser is now easy, as the new newuser is much easier to 
maintain than the old newuser.  But I don't think it needs to be 
changed for this as it already does what we're talking about.

resp:6 Yeah, that sounds like the one.  Can anyone read this and see 
if it applies to us?  I kind of think that it doesn't, as we don't 
collect information for "commercial" purposes, and it seems to 
specifically exempt non-profit organizations, but I am now a lawyer 
and all that.

There was a line in there about not applying to nonprofits as defined
in some FTC rule, so we'd need track back a little farther to see if
a 501C3 is considered exempt from being an "operator" under that law.
IANAL either.

I think that point would drive whether we *have* to ask for birthdate 
or not (and, presumably, newuser would have to do something if the 
potential user was under 13 years old).

We could slurp personal info when we need to populate .plan and the 
users home-page, and leave it out of account creation. 

Instead of asking for info directly, do it indirectly - show the user a 
snazzy web-template with pics and links to facebook and a wall and nice 
resume etc of some template user, and ask him if he'd like to create 
something similar.. there are classes of users:
1. kids in school
2. kids in college
3. kids just out of college (in technical fields, arts. etc)
4. working ppl with hobbies
5. hacker types
??
(so we'll need a good web-template for each.. something like Facebook 
or hyves.nl or bebo - but much more elegant, clean and personalized)

Sounds really overly complex.

How would all that information be used?

resp:12 What information are you referring to, specifically?  Right 
now, the stuff we ask for get's put into the user's .plan file.  Well, 
the email address gets used to email the user their new password.  The 
only other real use is for resetting passwords if the user forgets: 
traditionally, this was done via an emailed request; if the user's 
plan is private, but has information that could be used to verify the 
user's identity in it, then staff could look at that and ask the user 
a question based on it to get at least some idea that they are who 
they say they are.  Of course, if the request comes from the email 
address the user used to register, then that's not really necessary.

I'd rather we didn't complicate this newuser process.  It's not about
how much information we can collect or about customizing the information
we collect.  It's about collecting less information and making the
process of creating an account simpler and faster.  

In my opinion, if we do ask for optional information, it's good if we
do it directly.  Then people can ignore what they don't want to have
appearing on their accounts.

resp:12 nope, darn - me unclear:
1. Strip newuser to the barest minimum.
2. If the user decides to do the mkhomepage/mkplan routine, then ask him
 for stuff - meanwhile highlight the cool home-pages bit in motd and on 
the site

resp:14 Is it really complicated right now?

Has anyone run newuser recently?

I must admit, I'm patently confused about what people want here.  Are we
stripping things out of newuser or not?  What *should* be there?  Can we
get a concrete list?

When I took a look at the web newuser it was the usual questions about
all the details and settings, so yes, somewhat complicated.  I realize
it isn't complicated for anyone who has set up a Unix acount before, but
for the uninitiated it can be quite complex and confusing.  And time
consuming. If this extra information is not needed for people who want
to access Grex via the web, I'd question the value of collecting it.

I'd probably strip it back to full name, login id, password, optional
telephone number and optional e-mail address, assuming we can use some
default values for the other information like shell, terminal type,
backspace key, etc.  I'd be interested to hear what others think of this
idea.

I tried to run the web newuser on Nov 22 and it failed.  The command
line newuser was successful.  Has there been a change to the web newuser
so that it actually creates an account?  If so, this should be announced
and it would be good if we said something about it on our web page.

I see it still errors out today: 

Your application for an account on Grex has not been processed due to a
system problem.

    * Could not access directory /usr/noton/nu/ 

Sorry. This system error has been logged and will be addressed by our
staff. Please, try again later.

I'd say we probably want at least the Board to hear about this.  We can
discuss at our next meeting, unless we all think it's a good idea to do
it now.  What do the rest of staff think?

resp:17 We seem to be talking at cross-purposes.

I haven't written the new web newuser yet; the one that's current
there is the old broken one.  It has not been streamlined, or even
changed in any way in the last couple of years; perhaps longer.
I'd like to get to the new one soon, but I've got other things going
on in life than just Grex, and I've been devoting a lot of time to
Grex lately and it's been interfering with some of the things that
I've got to get done.

So what I'm saying is, give me a little more time to get that up
and running; what's running *on the web* is not currently representative.
When I'm saying "try newuser", I mean the one runs when one logs in as
"newuser" on grex using SSH or telnet.

>I'd probably strip it back to full name, login id, password, optional
>telephone number and optional e-mail address, assuming we can use some
>default values for the other information like shell, terminal type,
>backspace key, etc.  I'd be interested to hear what others think of this
>idea.

We need the email address to email the password to the user.  Newuser
generates a password and emails it to the user.

You don't need to set defaults for:
* terminal type
* backspace key

The terminal emulators and connection programs and tset figure that stuff
out these days.  The user gets to pick a shell once they get validated or
verified.

>I tried to run the web newuser on Nov 22 and it failed.  The command
>line newuser was successful.  Has there been a change to the web newuser
>so that it actually creates an account?  If so, this should be announced
>and it would be good if we said something about it on our web page.

No, there's been no change.

>I'd say we probably want at least the Board to hear about this.  We can
>discuss at our next meeting, unless we all think it's a good idea to do
>it now.  What do the rest of staff think?

This is where I'm confused.  What do you want the board to hear about?
What are we discussing, exactly?  I really need a clear, concise answer
to this to know what direction to head in on this.

It's a relatively significant change to an application that's been in
place for eons, so keeping the Board and the rest of staff in the loop
would be good, I think.  It's also good to get multiple opinions on your
question of what exactly needs to be asked by newuser.  We don't usually
get opinions from many people in coop.

Anyway, I understand about other priorities, so don't feel you need to
attend to Grex constantly.  I see the error I got out of the web newuser
was different than the one I had on Nov 22, so something maybe changed.
It doesn't look like it's too far off from working if the most recent
message is accurate.  

In the short term, what we need is to have the web newuser working as it
used to, using the old program.  If that's easy to do, great, it'll give
us more time to hash out the details of any changes.  If not, then we'll
just have to be patient.

Actually, I think the short term solution is to get the new one written.  The
code that's there now is, well, complicated and confusing and very, very old.

Looks like /usr/noton/nu doesn't exist so that's why I got that error.
But if the new one is easier to get in place and it works, that might be
better (and more maintainable).

Re #13: "What information are you referring to, specifically?"

The info listed in #10. We don't think weneed to do a demographic study 
on all newusers.

Here's what I see we need to do, in order of priority:

  1. Get the web newuser working.  If that means getting it working
     as it did when it was last working, with all the questions and
     technical stuff, so be it.  Not having it working at all is more of
     a harm to us than a complicated new user process.

  2. Simplify the web newuser.  From what I've seen we should be able to
     do this if we have a working web newuser and just use some default
     values or no values for options, for the things we're no longer
     asking (in the data submitted from the web page).  If this is not
     the case, speak up.

     The "how" (or "how much") to simplify is one of those consensus
     questions we get from time to time.  Let's give the Board and Staff
     and the rest of the users some time to weigh in.  Perhaps they see
     other issues with any simplification proposal.  If we hear nothing
     in a reasonable amount of time (e.g. 1 week), I'll assume no one
     has an objection.  Then let's simplify it and see how it works out.

Let me know if you see issues with this process (such as it's more work
to re-do the web newuser or web page to simplify it than it is to just
take the time to simplify all of it now).  We can adjust accordingly.

(I've also e-mailed staff and board with a summary of what we're talking
about in this item).

resp:23 I've got to be honest.  I *really* think you're making it too 
complicated, and involving too many hands into the pot.  Consensus is 
great, but Grex is riddled with inaction because people wait and wait 
for consensus that never comes.  And most of the time, it's for 
inconsequential things that people just don't care about.  Whether we 
ask for somebody's hobbies or not is probably one of those things.  
People will debate endlessly about it, but in the end, I really doubt 
that anyone here *really* cares.

Web newuser has been broken for several years; if it's down for 
another week, the world won't stop turning.  Let's just decide what 
questions we want to ask and program to that.  It'll be less work to 
do it all now as a unit than to fix the terrible code that's there now 
and then change it down the road.

I understand your point of view, Dan.  Maybe it's time to not try so
hard for a consensus or the involvement of others and just get things
done.  From what I've seen, generally, the people who care have little
or no interest in actually making things happen, so I'm tempted to just
say "do it this way" and let the chips fall where they may.

I am all for getting things done. If I ever make a stink about
something, please feel free to refer me back to this post ;) 

resp:25 Thanks, Kent.  Don't get me wrong, consensus is good, but it's 
also this community's achillies heel.

resp:26 Quick!  Someone upload slynne's post to wikileaks!

Re #27: "consensus is good, but it's also this community's achillies 
heel". No kidding. I won't participate on boards of organizations that 
do things by consensus. I'm a "straight up and down vote" person (with 
Roberts Rules.....).

Re resp:20 - "Actually, I think the short term solution is to get the
new one written.  The code that's there now is, well, complicated and 
confusing and very, very old."

I quite agree.  Web newuser is around 2400 lines of C source code, and
the TTY-based newuser around 5700, code that nobody currently active on
Grex had anything to do with writing.  Wading through that to fix
problems, when a new TTY newuser is already in place and a new web
newuser shouldn't be far behind, strikes me as not worth the effort.

Having code that is easier to maintain is a plus, I think.  I know from
personal experience that wading through someone else's code can be a
lot of effort depending on how it is written.  Sometimes, it's easier
to start from scratch, and faster than trying to fix old code that is
confusing.

resp:29 Agreed.

resp:30 The new newuser needs some cleanup, but overall, I think it's a lot
less crufty than the old newuser.

  
re 18 ... uhhhhh....
  

 We need the email address to email the password to the user.  Newuser
 generates a password and emails it to the user.

let;s not do that .... struturally it;st not a good idea.
  
keep resh and with the modificatoins./clarifications that validationg is goign
to require email -exchange- with someone staff/board on grex. 
  
i.e.. after crateing an acount (and the laert in newuser that
other-email-addrs is needded for validation) a validationg rqeust can be sent.
  
sent by the newuwer from (possibly other-email-addrs) or frm grex-email,
whichever.
  
emaikling passwds makes me puke. 
  

What's not a good idea about mailing the password?  This isn't the
Pentagon or anything. We've talked about an an offsite e-mail address
being more or less required, as in automatically send the user an
e-mail and they can respond and be validated.  It also gives us contact
information if there are other issues (including forgotten password).

I suppose we could require the password be changed when they first
log in.  Or at least, suggest strongly that they do so in the e-mail
we send.

resp:32 Why?

resp:33 Resh requires the new user to change their password the first
time they login.  Actually, it requires them to change whenever there's
a certain file in their home directory.

Okay, then, sounds like we're in good shape.

  
first of all .... about emailing passwdds... whe a newuser cone here she/he/it
creates a passwd.
  
wtf is wrong with that? notiohing.
  
second, the balidation is a time dalya, eveninfit is 30 secs.
  
third.  hte eamil to the newuser may ot be read (or it might og iotn some spam
foledre) and be unknown for monthsl. (rt stuff is expeirience as is ... my
emaoil)..
  
i ahve  validated .. well tried to valisdate ... reaped loginds .. which
prompted me ... a wheil aago ... to ask aobut hte reapo  preocedure.  wheat
i had to send was "well create your loginid AGAIN .. and i wiell validate"
  
fourth .. a passwd distting around for a whiel is STUPID (imnsho) wheich is
also different from the newuser's orogianl choice .. w t f ?
  
there is more but the above is enough, i think.
  

I'm going to address your post point by point.  I'm also going to take
the time to fix your spelling errors.

> first of all .... about emailing passwords... when a newuser comes here
> she/he/it creates a passwd.

That's not true anymore; the user isn't even prompted for a password.
Further, there's nothing that says that they *have* to give a password
to newuser.

> wtf is wrong with that? nothing.

Actually, it became a vector for abuse.  I have caught specific people
making *thousands* of accounts with scripts.  This way, at least we can
track that back to an email address.

Second, by generating the passord and emailing it to the user, at least we
have some sort of useful contact information: if the user logged in at all,
we know we've got an email address for them.

Lots of sites do this: ask for an email address and email an auto-generated
password to the user.  It works just fine all over the Internet.

> second, the validation is a time delay, even if it is 30 secs.

What validation are you referring to?  The automated validation of the
email address that newuser does?  I'd say that in the worst case that
might take half a second.

Or are you talking about how long it takes for the user to get the email
so they can login for the first time?  It takes a few seconds.  The upsides
are worth it.

> third.  the eamil to the newuser may not be read (or it might go into
> some spam folder) and be unknown for months. (rt stuff is experience as
> is ... my email).

It strikes me that if a user is interested in getting an account on Grex,
they won't mind getting an email with their password.  Evidence of this is
all over the net; it's more common than not for users to get passwords
emailed to them than otherwise.  If they wait for months, well, that's on
them and they weren't likely to be very interested anyway.

What's the difference between a user logging in once automatically at the
end of creating their account and never logging again, and never logging in
because they didn't bother to read the email that we told them they were
going to get?
   
> i have  validated .. well tried to validate ... reaped logins .. which
> prompted me ... a while ago ... to ask about the reap  procedure.  what
> i had to send was "well create your login id AGAIN .. and i will validate"

I don't know what this has to do with newuser emailing passwords, except
perhaps an extension of the above paragraph about the user not reading his
or her email for months.  Newuser is pretty explicit about telling the
user, multiple times, that it's going to send them email.  If they choose
to ignore that email, then they're just as likely to login to resh, see
they can't run BNC or upload udp.pl and disappear after one login.

The policies and criteria by which we decide to reap accounts have not
changed for years.  If it takes the porters months to do validation, then
that's a real problem.
   
> fourth .. a password sitting around for a while is STUPID (imnsho)
> which is also different from the new user's original choice .. w t f ?

What do you mean, "is also different from the new user's original choice"?
Do you mean a password that they enter, or a password that they have in
mind when they create an account on Grex?  If the former, they don't enter
a password.  If the latter, I claim this is actually *easier* on them
since they don't have to sit there and think of one.

To be clear, here's the basic process for getting an account on Grex:

1. Login as newuser and enter your basic information:
   a. "Real" name.
   b. Email address.
   c. desired login name.
   d. Currently, a few other questions: address, phone number, interests, etc.
   * Note that password is not on this list. *
2. Newuser generates and emails you your password.
3. User gets the password, logs in and is in resh.  Resh sees they've
   got a special file in their home directory (I believe I named it,
   ".needspwchange", but I can't remember) and prompts them to change
   their password.

That's it.  Suppose we go on through the validation process.

4. User goes through the validation process:
   a. send email to porters@grex.org with the request,
   b. get an email back saying, "How'd you hear about Grex?"
   c. user gives some response (really, any response will do),
   d. a porter runs "validate user" on Grex, thus changing their
      primary group to "people" and changing their shell to
      /usr/local/bin/newly-validated (this will move to /cyberspace/bin
      soon, though; the path is unimportant).
5. User logs in again (note that they changed their password the first
   time they logged into resh; it doesn't change at all during the validation
   process).  Newly-validated chgrp's their files to the "people" group
   and invokes /usr/local/bin/pickashell (again, this needs to move to
   /cyberspace/bin, but the path doesn't matter); the user picks what shell
   they want to use and away they go.

Now the user has real access to Grex.  Supposing that they wanted the
full, unrestricted access, then go through the existing procedures, which
haven't really changed since Grex was created, to get verified: basically,
this means that they send a copy of an ID or a personal check or use
paypal, at which point someone runs "verify user" on them, which changes
their primary group to "verified" (and that's basically it; it also adds
them to "people" as a secondary group).

What I'd like to do, and what board talked about somewhere on the order
of three or four years ago, is add an automated verification system.
Basically, the user types "verify" or something on Grex, gets a URL that
they click on, they pay a couple of bucks or something through PayPal,
PayPal contacts us, we verify the payment and automagically verify them.

> there is more but the above is enough, i think.

No, I'm afraid it is not.

You are making a lot of flimsy assumptions (that the user won't
read their email, or that it will get marked as spam) and predicating
your argument on things that haven't been true for years (that the
user comes to Grex with some idea of what they want their password
to be, probably also that this is some sort of huge security risk).
It isn't 1991 anymore.

I think that what newuser is doing now is actually much better than
the old system:

a. It avoids abuse.
b. It gives us much higher quality contact information (we actually
   have an email address that we know works in case the user forgets
   his or her password).
c. It makes contacting the user simpler: we can look at newuser's
   contact logs to get a user's email address if we want to send them
   a message, instead of digging through their personal files (which
   TS does regularly in order to find email addresses for validation
   purposes).
d. It gives an air of professionalism to Grex that, I claim, will
   increase users, not drive them away.
e. It follows well-established and widely used precedent.  Indeed,
   even on Grex, when we reset someone's password, we just send
   them an email.

Does anyone else feel that emailing the password to the new user is
bad?

well.. i'm not clear on one point..
1. we ask for his email and mail him his password, AND put him in resh?
How does he move from resh to bash??

2. we can try to avoid the spam problem by making the content in the 
email a little dynamic.. Dear so and so, blah blah and in the Subject: 
Grex registration information for account blah.

resp:38 See steps 4 and 5 in resp:37.  I really doubt the spam problem
is much of a concern, to be honest.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss