On 8 November 2010 16:41, Curtis Hovey <[email protected]> wrote: > On Mon, 2010-11-08 at 11:32 +0000, Matthew Revell wrote: >> > 2. The description of what a user can see vs. project roles was >> > confusing. I have invented two terms that I hope summarise >> how >> > bugs and branch subscriptions work, and how we will allow >> > projects give trusted persons power to see all private >> > artefacts. >> >> I think these terms (presumably "observer" and "restricted observer"), >> along with "disclosure" are where we'll have most scope of confusion, >> initially. > > "observer" and "restricted observer" are only used in this 4th version. > I invented the terms last week. Disclosure was said by me in > conversations, but it was not used in the UI. Versions 1-3 use terms > like access and view, then I added in read and write in versions 2 and 3 > because users assumed the first two terms implied change.
I like all three terms and, without having spoken to any potential users, I think they're pretty clear but we made need to watch for how much people understand of each term. > I used the terms owner, driver and bug supervisor in versions 1-3 > assuming/hoping that the testers would understand those roles had change > power. That was not the case. adding terms like read and write > reinforced an expectation of Unix ACL controls on all objects instead of > clarifying that project owners could permit someone to see some or all > of a project. We are not creating an ACL system. The only non-UI change > the feature proposes is that we add an alternate mechanism to > subscription to give someone access to all private data. You've mentioned a couple of times that we're not creating an ACL system. To my, perhaps naive, view an ACL is a list of people who can read and/or write certain data. Is that right? I want to be able to look out for confusion between what we're testing and an ACL system. > I introduce the new terms "observer" and "restricted observer" make it > easier to talk about what a user can do in a project. They are easier to > understand in a conversation about owners and bug supervisors. > > Keep this in mind. Any user who can see a private bug can comment on it. > That is true today, and there is not discussion of changing this rule. > So we are not really talking about "read and write", and an "observer" > can converse. Thanks. I propose the following: * Two rounds of user testing. - Between rounds 1 and 2 we'll update the mock-ups based on round 1's data. * After round 2, a follow-up survey sent to all of the participants to check that any points of confusion etc have been clarified. I had considered whether we should split each round into two parts: one targeted at private project owners and the other at observers/restricted observers. I imagine, though, that the experience for observers/restricted-observers won't be much different to what already exists. How will observers be notified of and manage their access to private items? Looking at the mock-ups, I think it'd be helpful to have some additional mock-ups. These would just be variations on what you've already produced :) * The page from which the disclosure listing is accessed. * A version of the listing page without the people picker overlay. * A version of all mock-ups without explanatory boxes or post-it notes. Would you be able to provide those? If so, let me know roughly when and I'll start booking people in. Cheers! -- Matthew Revell -- https://launchpad.net/~matthew.revell Launchpad.net -- cross-project collaboration and hosting _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
