[Design][Proc]Proposal for a nag-reminder feature
mimi at osafoundation.org
Wed Jan 11 19:46:44 PST 2006
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
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
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
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
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
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
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?
On Jan 11, 2006, at 4:45 PM, Philippe Bossut wrote:
> Alec Flett wrote:
> 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.
> - Philippe
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Design" mailing list
More information about the Design