On Wednesday 05 July 2006 10:20 pm, Elliot Lee wrote: > Hey Tom! Thanks for keeping us on task here :) > > Here are some of the things I have been thinking of for the new > account system: > > For users: > - Allow listing more than one e-mail address per account > (linkedin.com is the site I remember doing this right) > - Clean up the interface > - Have a top-level menu that is shown on all pages, with quick > links to different pieces of the account system > - Allow doing the sign-up process as a wizard-style step-by-step > interface, instead of a bunch of random links to > - Make documentation a part of the interface > - In particular, there is a lot of concern that getting a GPG key > is too complicated for a lot of people such as translators, who are > not technical types. We need to make that process as clear and simple > and documented as possible can we provide a script for nontechnical types? > - The user info screen might want to evolve from just an "edit my > information" screen All sounds good I read it to mean simpler and more integrated > For administrators: > - Clean up the interface > - With hundreds of users and 10s of groups, we definitely need a > nicer way to find specific users or groups than paging through them 1 > by 1... > - The part of the interface where you add users to or remove users > from a group is clunky. In particular, it's currently possible to add > a user to a group more than once, and if a user is rejected from a > group, there is no way to let them come back at a later date and > reapply... > - Make the e-mail reminders a bit smarter and nicer to read > - Allowing administrators to mark membership applications as > "acknowledged" would be nice for administrators, especially for Extras > - Allow setting a per-group e-mail message to be sent to people > when their membership in a group reaches different stages... > - Allow groups to be members of other groups (i.e. you are a member > in group B because you are a member in group A, and A is a member of > B). Can't do this nicely with the current SQL schema. I did it nicely > with the old Red Hat build system, but it requires using text fields > instead of numeric IDs to specify the names of the group members... with the right interface it shouldn't matter if GID's/UID's are numerical or text > For everyone: > - Need more free-form text fields everywhere (e.g. comments that are > visible only to admins, or whatever). Maybe it should just be > something that holds XML that is processed by the apps... > - Privacy issues need to be thought out more clearly and addressed. > In particular, this relates to what information we store > - Need to make iron-clad sure that the rewrite does NOT muck with > the legal issues surrounding the CLA (i.e. we have to continue to > guarantee that people have submitted the CLA form by a GPG signature > with a key that is tied to a verified e-mail address) > - Account System 2.0 should get run by Red Hat's legal department > to just make them feel comfortable with the change I would imagine this is a must. We cant freak them out :D > - On a related note, we need to add proper support for the corporate > CLA. If we had 'groups being members of other groups' implemented, it > would be fairly easy to create a group for each corporation that > signed the CCLA, have each of those groups be a member of the > cla_done group, and having access to the corporate CLA groups > administered by a designated contact... Sounds good. is there many corporate CLA's? > Behind the scenes: > - Rewrite the code to be cleaner (maybe use turbogears, or maybe > that is too heavyweight) > - Make it easier to embed into other apps, especially the signup > process (so that Extras can have a custom "sign up as an extras > contributor" wizard that can easily do the basic account system steps > as part of its workflow > - Figure out the whole LDAP vs SQL thing Why not use both? some thing will be just easier in ldap, some in SQL, use SQL as a backend to ldap Its a little more work but would provide greatest flexibility. > - At the end, port the application interface parts (get_auth, > have_auth, have_group, etc.) to perl and php so that we can use them > from all our applications > > Hope this helps, > -- Elliot -- Dennis Gilmore, RHCE Proud Australian
