Separately: we should include a short help text that defines who's supposed to be able to do add/delete/change operations, along with links to the specific PMC how to documentation. Especially if we end up with an auth where members could technically do things that socially they shouldn't (i.e. for PMCs they're not on).
John D. Ament wrote on 6/22/17 10:40 PM: > Hey guys > > I finally got time to write down in confluence the first sketch put > together for the new roster tool. You can find it here: > https://cwiki.apache.org/confluence/display/WHIMSICAL/Roster+Tool+Option+1 +1 chair's row should be edit-only. If we get fancy, include a ? button in place of any edit button that links to the "how to change PMC chair resolution" page. +1 to somehow including an "x" delete button; PMCs need to be able to do that operation as well. > > A few notes of what went into this: > > - I demoed the IPMC roster page > - I demoed the phonebook > - I showed a "day in the life of" where I demoed how Trevor Grant was added > to the incubator committers, Steve Blackmon to the IPMC. Where/who did you demo with? 8-) > the identified pieces missing included: > > - How to find existing committers The search box isn't completely clear to me: if you're just finding committers within a PMC, how is this faster than CTRL-F to use the browser search? *If* someone wants to integrate that into the table itself, so it intelligently highlights/re-sorts the table in place to show you matching entries, that would be super-cool, but a lot more work than we really need for something functional. > - How to add someone new > - How to change someone existing's roles I definitely like a single table with a new column showing (P)PMC/committer status; much simpler to display and look through. Columns do need to be sortable though. > - How to make bulk changes > > The a-ha moment came when I showed bulk how bulk changes work right now. > The main points are that someones role should be represented as a combo box > (especially since PMC/PPMC implies committer) to chose which level someone > is (from a list of options). +1, adding someone with check/combo into what role(s) is great. > Add should append a new row to the table, and > you do searches from there, an autocomplete component ala > https://jqueryui.com/autocomplete/ was suggested . Once someone has been > added in some way, the username column is not editable. Removing someone > is ambiguous. We don't do it much, so either there's an option in the > combo box for "emeritus" or a delete icon on the right. I'm inclined to > say emeritus to better match our policies, but I'm not sure we track that > info right now. No, please do not use emeritus. While some PMCs use it as a social convention, from the board's point of view, individuals are either on a PMC or not on the PMC - there is no other state. > The table should include everyone, not separate tables per > role. It becomes hard to find people. The inline search should just do a > basic text match against the row. E.g. if I type in committer it should > show all committers. Is within-column searching that important if the table is sortable by all columns intelligently? I.e. when you click to sort by PMC/committer, it uses the name as a secondary sort column, making it easier to find names that way. > Moving save outside reinforces the bulk operation > feel. Instead of making single changes you're always making multiple > changes at once. I'd need to see a more detailed example (and run through the concept myself). But I agree: we need to make the action button that submits changes *very* obvious as to what it's saving, so users clearly understand that. > > Thoughts? > > John > -- - Shane https://www.apache.org/foundation/marks/resources
