launchpad-dev team mailing list archive

[Matthew Revell <matthew.revell@xxxxxxxxxxxxx>]

On 8 November 2010 16:41, Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx> 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