I started up the wiki page for the requirements on the new account system. It is at http://fedoraproject.org/wiki/Infrastructure/AccountSystem2 . There isn't that much there now. The last time I sent the list of enhancements request out, I really didn't get many enhancements back. There was just a discussion on what the backend technology should be. I did pull out one feature.
Give more information about a user when deciding to sponsor a person. EG. bugzilla enteries
This time around I would like you all to just give me a list of enhancements and not worry about the implementation details as much :) . I really want to have some good stuff to report in tomorrow's meeting. Please help me out :).
~lyz
Note, this is a laundry list. Some of the stuff on here may fall under other infrastructure projects more than this one. Some of it may be impractical. The common thread is that they link to a person contributing to Fedora.
Better UI ========= - Search for a packager by regex on realname, username, email or irc nick. + Limit search by membership within group: find .*badger.* in cvsextras. - More connected. Being able to refine a search for a user from within a group listing, for instance. - Better display of users. If you are viewing cvsextras and trying to get to a user whose name you think starts with "n", you'll have a lot of links to click.
One-stop Fedora Accounts Tracking ================================= - Integrate with moinmoin - Integrate with Zope+Plone - Integrate with the revision control system, package builders, etc. - Integrate with bugzilla
"Portfolio View" of contributor's work ====================================== - Packages worked on - bugzillas replied to - upstream projects they work with - wiki/Plone/Docs project pages they work on - arbitrary URL + descriptions.
-Toshio
On Wed, 2006-07-05 at 18:34 -0500, Tom Lynema wrote:
I started up the wiki page for the requirements on the new account system. It is at http://fedoraproject.org/wiki/Infrastructure/AccountSystem2 . There isn't that much there now. The last time I sent the list of enhancements request out, I really didn't get many enhancements back. There was just a discussion on what the backend technology should be. I did pull out one feature.
Give more information about a user when deciding to sponsor a person. EG. bugzilla enteries
This time around I would like you all to just give me a list of enhancements and not worry about the implementation details as much :) . I really want to have some good stuff to report in tomorrow's meeting. Please help me out :).
~lyz _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
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 - The user info screen might want to evolve from just an "edit my information" screen
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...
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 - 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...
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 - 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
On Jul 5, 2006, at 19:34, Tom Lynema wrote:
I started up the wiki page for the requirements on the new account system. It is at http://fedoraproject.org/wiki/Infrastructure/AccountSystem2 . There isn't that much there now. The last time I sent the list of enhancements request out, I really didn't get many enhancements back. There was just a discussion on what the backend technology should be. I did pull out one feature.
Give more information about a user when deciding to sponsor a person. EG. bugzilla enteries
This time around I would like you all to just give me a list of enhancements and not worry about the implementation details as much :) . I really want to have some good stuff to report in tomorrow's meeting. Please help me out :).
~lyz _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
On Jul 5, 2006, at 23:20, Elliot Lee wrote:
- Privacy issues need to be thought out more clearly and
addressed. In particular, this relates to what information we store
Argh, forgot to finish that thought...
Basically, we need to think more about what information we store, but even more importantly, what information is displayed to the general public when viewing a user's info, what information is displayed to registered Fedora users when viewing that user's info, and so on.
It's good to ask people in Europe about these issues, since they tend to be a lot more privacy conscious than those elsewhere.
Best, -- Elliot
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
On Jul 5, 2006, at 23:38, Dennis Gilmore wrote:
- 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?
One good possible solution...
- 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
Argh, ANOTHER thought I forgot to finish - thanks Dennis! :)
I meant to say that instead of just letting the user edit their information, we should also have links to other places where they might want to change their settings - the Wiki, OTRS, package database, bugzilla, etc. - and maybe a status summary from each of those places.
- 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
This was where I diverged into an implementation detail rather than stating a problem. At the SQL schema level, it does matter. All this should be totally transparent to the user...
- 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?
I believe Dell and IBM are the only ones (I know Dell, not sure about IBM).
- 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.
Can you explain more of what you're thinking in this area? In my thinking you have to have one authoritative place to store the data, and while you can do things like offer other interfaces as desired, it's not really a matter of using two solutions where one will do...
(BTW, how hard would it be to implement an LDAP server whose tables were the direct results of SQL queries, with no gatewaying done? Is there a python module to make it easy to implement an LDAP server?)
Best, -- Elliot
On Wednesday 05 July 2006 11:03 pm, Elliot Lee wrote:
On Jul 5, 2006, at 23:38, Dennis Gilmore wrote:
- 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?
One good possible solution...
- 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
This was where I diverged into an implementation detail rather than stating a problem. At the SQL schema level, it does matter. All this should be totally transparent to the user...
that was what i was trying to get to the user should have no clue of the implementation. I could be wrong but i think it could be done either way
- 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?
I believe Dell and IBM are the only ones (I know Dell, not sure about IBM).
So not huge but with it being easy for the corporate type to participate It could encourage others to sign up
- 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.
Can you explain more of what you're thinking in this area? In my thinking you have to have one authoritative place to store the data, and while you can do things like offer other interfaces as desired, it's not really a matter of using two solutions where one will do...
What i was thinking was to keep the authoritative data in a SQL server with ldap server as a client
http://www.flatmtn.com/computer/Linux-LDAP.html provides one way to implent. I personally have not done it. But i think it could be an option.
(BTW, how hard would it be to implement an LDAP server whose tables were the direct results of SQL queries, with no gatewaying done? Is there a python module to make it easy to implement an LDAP server?)
Best, -- Elliot
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
infrastructure@lists.fedoraproject.org