Yash Mehrotra writes: > *My Ideas - * > 1. One issue currently as mentioned is owners of multiple lists have to go > through all the pages for changes. I think we should show all the mailing > list's requests,subscriptions etc. all in one page.
This isn't a dashboard-level issue; this should be a facility at the core level -- the core knows which lists the user is responsible for, and what the pending tasks are for each. Are you sure Mailman 3 + Postorius doesn't have this capability already? > 2. The new list features should be opened from a different tab as a list > admin doesnt do this every day. > > *The primary focus should be - to make it easy for an admin to do his daily > activities.* I agree with the general statement, but are the new list operations really a problem if displayed on the main dashboard? > 3. So, the index page will contain stuff mentioned on point 1, and the > there will be different pages for other stuff like - create/delete > list, view statistics ( see next point) My experience with a non-web-based moderation system is that most moderation/subscription requests can be judged from a one-line display, and for more complex operations (eg, banning an apparently abusive would-be subscriber) use Web 2.0 tech like Javascript popup menus. Of course they have to degrade gracefully if JS is disabled, and even if CSS is disabled. But the main interface probably can include list creation/deletion and a few interesting stats. > 4. We can also provide some basic statistics for a mailing list > like which user is most active, how many avg, mails are sent in a > day etc. I don't understand why this belongs specifically on an admin dashboard. In most cases subscribers probably care more about it than admins do. > 5. We also also give each list its individual page, so the admin > can do list specific functions like, say change settings , That's an ancient interface, and doesn't really come up to the expectations people have when they hear "dashboard". All your pending tasks (including those you initiate like list creation) should be available conveniently as soon as you log in, and as much as possible which features are available should not depend on the currently. > ban user etc. This will almost certainly turn out to be horrible UI. Experience shows that banning a user based on an abuse detected during moderation or subscription approval, and so it should be available without leaving the dashboard. > 6. One more cool feature would be to color code different types of things > for visual ease. Eg. Subscription requests can be color A. Held messages > can be color B. and so on. This will not only help the administrator but > also would visually good to look at. Maybe. On the other hand, maybe users will prefer to have the tasks grouped (a group for subscription requests, a group for moderation, a group for admin-initiated actions like list creation if permitted, etc). Maybe color coding will "look nice", but IMHO it's unlikely to be a big efficiency enhancement compared to grouping. > I will add more stuff based on your feedback. Sorry, that's not the way this works. Part of GSoC to determine requirements. You tell us what you plan to do, we decide whether we like it better than somebody else's proposal. Most likely, if you seem to have overestimated your productivity we'll tell you you can cut back your proposal, and where to cut. But if you propose something trivial, mostly you'll get the simple comment "this is not enough to be a good GSoC project." A dashboard that gives convenient access to all tasks a user is assigned seems like a GSoC-sized project to me (maybe bigger). The main thing you need to add is a schedule. See also http://turnbull.sk.tsukuba.ac.jp/Blog/SPAM.txt. _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
