[Design][Proc]Proposal for a nag-reminder feature

[Mimi Yin]

I guess maybe there is a cultural aspect to consider. There is an  
element of anonymity in design process. The idea being that everyone  
(designers, engineers, users) contributes ideas, analyses and  
feedback at various stages of the process and that the resulting  
design is not any particular person's idea or a combo meal of ideas,  
but a synthesis of contributions, worked, reworked and massaged into  
a homogeneous and coherent whole that is greater than the sum of its  
parts.

I realize that perhaps this is anathema to some fundamental  
assumptions of open source development: scratch your own itch,  
excitement that others are using *your* code, etc...But I feel  
strongly that

1) anonymity and
2) more focus on user goals and needs and
3) less emphasis on particular ways (features and widgets) to meet  
those user needs is crucial to any design process...

...especially a collaborative design effort that very badly doesn't  
want to turn into design-by-committee.

My secret fear is that tracking "design ideas" as discrete features  
in bugzilla is the exact kind of thing that takes the focus of design  
discussions away from users and workflows and instead fuels "my  
widget" versus "your widget" debates.

I guess what I'm trying to say is that design idea contributions,  
even if they come to us as discrete feature descriptions (which is a  
perfectly valid way to start), need to be rephrased in terms of user  
goals...at which point, they are no longer appropriate for bugzilla.  
So I might rephrase the "nag reminder bug" as:

Need to help users keep track of tasks over time. Which would then be  
followed by a general discussion about the many different ways to  
address that user need, a nag alarm being one of them. Which does not  
sound like something appropriate for bugzilla to me. I think a wiki  
page + discussion would be better.

Design contributions that I *would* consider appropriate to track as  
discrete items with some notion are concrete deliverables: mock-ups,  
icons, visual specs, color palettes, layout explorations, etc. These  
are things that would definitely be worth tracking in bugzilla as  
design contributions.

Of course I also see the other side of the problem. There is  
legitimate fear that anything that goes on the wiki and in the design  
list are lost forever.  (This is why we're building Chandler right?  
To address this very question: How do you keep better track of  
amporphous information (as a group) that isn't in some strict  
database of discrete items such as bugzilla?)

Nonetheless, I think it's not an accident that the design list and  
wiki is where most of design work takes place. The qualities that  
makes information harder to track in these forums are the same  
qualities that facilitate more fluid and coherent design discussions.

Ultimately, if the Design Team is the primary consumer of community  
feedback, then we need to come up with a way of capturing and  
tracking feedback that works for us as well as the community.

I agree that what we have today isn't perfect, but we need to have an  
opportunity to evolve a system that works within the context of the  
design process we believe we need in order to be effective and  
productive.

That being said, I'm open to letting bugzilla be one of the places  
where we store design ideas for now until we come up with a better  
system.

Katie also suggested that we try adding a tag to design ideas  
suggested via bugzilla, something that communicates: this submission  
has been moved to the design list for more contextualized discussion.  
A "Discuss amongst yourselves" tag?

Mimi

On Jan 11, 2006, at 4:45 PM, Philippe Bossut wrote:

> Alec Flett wrote:
>
>> Thoughts?
>
> I feel the whole tension (between Alec and Mimi's views) comes from  
> 2 directions:
> - Bugzilla is only good for very precise clear cut tasks or bugs,  
> some aspects of design are multiform and fuzzy by nature: I'd agree  
> with Mimi that some discussions are not about features but  
> scenarios, ideas that need to be decanted into features through,  
> precisely, discussion. Filling very fuzzy Bugzilla records can be  
> very counter productive (e.g. "Better scheduling workflow"...). I  
> for one reassigned bugs to Mimi when I thought that the description  
> was simply too vague to be assigned to a dev yet (not that this is  
> bad as I'm sure Alec will point out... :) )
> - There's expectation set when something is filled in Bugzilla,  
> extra pressure on devs: I think I'd agree with Alec here that  
> there's actually no damage done and the expectations are a matter  
> of convention. It's just a database, a way to track work items in a  
> searchable way. The use of "Future" proposed by Alec is very  
> reasonable. You can also assign the record to yourself till it  
> matures a little if you're afraid of annoying anyone. See it as an  
> incarnation of a GTD "later" list if it makes you more  
> confortable... :)
>
> I'd say that once a design discussion gets to the point of  
> discussing features (whether or not we signed up implementing  
> them), one should not hesitate to log something in Bugzilla. Not  
> doing it may end up in ideas and decisions falling throught the  
> cracks of design list threads.
>
> Cheers,
> - Philippe
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design