On Fri, Jun 23, 2017 at 7:54 AM, Shane Curcuru <a...@shanecurcuru.org> wrote: > 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.
I see the 'dropdown' as the way to change an existing person's status. Perhaps: 1) emeritize/delete can be an option there. FWIWI share Shane's comment below about not using emeritze. 2) replace the dropdown with a pencil icon, and have clicking on that create a dialog box that walks you through the potential operations. >> 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. /me likes this kind of work. I often times see whimsy as a "hold my beer" type of project. Somebody wants to have a podlingnamesearch indicator on establish resolutions in the board agenda: lets do it! >> - 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. I agree that columns need to be sortable. Without this, the proposed design makes it harder to answer questions like "who are the mentors of this PPMC"? >> - 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. This is the weakest part of the proposed redesign, IMHO. Too many people have been exposed to things like google spreadsheets where you make a change and there is no need to do a separate save operation. Placing a save button at the bottom of a potentially long list is not sufficient. People will make changes, think that they are done, and close the browser window. My suggestion is to focus only on optimizing the bulk add operation, and make all of the other operations take effect immediately (though generally after a confirmation). Having an add button at the top take you to a dialog where you can select multiple people, select a single role, and add them all at once would be what I suggest. >> Thoughts? >> >> John > > -- > > - Shane > https://www.apache.org/foundation/marks/resources - Sam Ruby
