2003-02-19 - Minutes of mozilla.org staff meeting
Gervase Markham
------------------------------------------
Present: Brendan, Myk, Marcia, Leaf, Asa, Mitchell, Seth, Gerv, Scott,
Chris.
*1.3*
Beta delayed a couple of weeks; branching will be delayed about one week.
This is usual.
20-30 blockers left. That list is unlikely to grow. Need to get a handle
on these.
Stay on the trunk vs. branch - contention.
Don't want to repeat the mistakes of 1.2, with a long branch and not
very much testing.
After branch, big ticket items hitting trunk: e.g. Chimera.
Haven't heard a date from the calendar folks.
Have heard back from a dozen module owners and peers with their plans
for 1.4 and 1.5.
Drivers will be working to coordinate how this fits into the roadmap.
*Plan for 1.4/1.5*
1.4 is short-ish - customers making releases.
1.5 is stuff we want for the "year after 1.0" timeframe.
Brendan to write a new roadmap
Need to keep doing milestones, and make big changes incrementally,
rather than disassemble the world
Accommodate the big stuff, and plan around it, but we can't stop shipping
We have to stop taking big changes just before beta, and make more of a
difference between alpha and beta.
*Chimera/Camino 0.7*
"Camino" winding its way through trademark review. Hoping to have an
answer within the next few days.
That's the only release blocker.
*jkeiser's offered tinderbox3 and mozilla_tools for CVS*
Discussed jkeiser's interest in having mozilla.org host another
tinderbox rewrite and additional developer tools.
Asa to talk with mcafee and others about mozilla.org's tinderbox needs.
Gerv to mail the current module owner, as a courtesy, and tell him we
are thinking about hosting tb3.
*Talkback data request for research*
We are OK with him having the data if Shiva removes the personal stuff
and there is no privacy issue.
Pass the issue to Shiva.
*Splash screen*
Asa has a simple one done by Kerz - just the plain name "Mozilla" in
Revolution font on a plain background. No trademark issues.
Asa to send it to Gerv, to arrange for checkin.
Gerv
Christian Biesinger
> *Talkback data request for research*
>
> We are OK with him having the data if Shiva removes the personal stuff
> and there is no privacy issue.
I do find it interesting that talkback data is given away for research,
but mozilla developers still have no way to get to it...
Michael Lefevre
wrote:
> Gervase Markham wrote:
>> *Talkback data request for research*
>>
>> We are OK with him having the data if Shiva removes the personal stuff
>> and there is no privacy issue.
>
> I do find it interesting that talkback data is given away for research,
with the personal stuff removed...
> but mozilla developers still have no way to get to it...
the data is given freely when the personal stuff is removed - posted in
bugzilla, and summarised in files on ftp.mozilla.org. AIUI, the issue is
just privacy - what's needed is some automated way of mozilla developers
getting the data out of there minus personal info.
--
Michael
Gervase Markham
Basically, the above is code for "we don't have time to think about
this." We don't know if Shiva will actually let him have it - he may say
there's a privacy issue regardless.
Exposing talkback to the entire world is a hard problem because of said
personal data. We can't make everyone sign agreements. And presumably
this guy has official academic accreditation and so on.
Gerv
Boris Zbarsky
> AIUI, the issue is
> just privacy - what's needed is some automated way of mozilla developers
> getting the data out of there minus personal info.
Yes. Currently a lot of time is wasted by having volunteer QA ask
netscape QA to get talkback data (everyone's time, both volunteer and
netscape employee).
Christian Biesinger
> Exposing talkback to the entire world is a hard problem because of said
> personal data.
I personally would love it if I could just access the actual talkback
stack, given the TB ID. that would not be personal data...
> We can't make everyone sign agreements. And presumably
> this guy has official academic accreditation and so on.
Oh, yeah. I have no problem with letting him have it. I would just like
to be able to lookup TB stacks myself, for bug triage and fixing.
Brant Langer Gurganus
Here's an idea: Don't collect private information. Then you don't have
to remove it in order for the data to be used.
--
Brant Langer Gurganus
Default QA Contact, Tech Evangelism
Default QA Contact, Calendar
Boris Zbarsky
> This is being actively worked on. Shiva and the talkback team have (I
> believe) done most of the work to sanitize the data and have started to
> work on the interface and mechanisms for querying it.
Great!
Asa Dotzler
believe) done most of the work to sanitize the data and have started to
work on the interface and mechanisms for querying it.
--Asa
Christian Biesinger
> This is being actively worked on. Shiva and the talkback team have (I
> believe) done most of the work to sanitize the data and have started to
> work on the interface and mechanisms for querying it.
That's really great to hear!
Boris Zbarsky
> Here's an idea: Don't collect private information. Then you don't have
> to remove it in order for the data to be used.
The talkback client asks for the user's email and for user comments.
Not sure what the former is used for, but the latter can be incredibly
helpful in determining what the problem is (eg can include a URL and
steps to reproduce, and often do).
Unfortunately, the comments can often contain personal information as
well (eg the site the user was at, the user's name, etc). Such
information would need to be screened out.
Matthias Versen
Great !
I'm really sick of asking random Netscape People for TB stacks that I
need for bug triage.
I have stopped asking for those stacks because it's very difficult get
the stacks.
Matthias
Michael Lefevre
that's great. thanks for the info :)
--
Michael
Brant Langer Gurganus
What's the difference with putting such stuff in the Bugzilla then? The
user should no full well that the information will be used to solve the
problem. Also, e-mail is optional I believe, so there's no privacy
issue there. I've looked through the Talkback data captured, and it
only captures running processes, etc. not stuff that gives away personal
data. If people are sending personal data in their comments, they
should no better.
Michael Lefevre
wrote:
[snip]
>> Unfortunately, the comments can often contain personal information as
>> well (eg the site the user was at, the user's name, etc). Such
>> information would need to be screened out.
>>
> What's the difference with putting such stuff in the Bugzilla then? The
> user should no full well that the information will be used to solve the
> problem.
yes, but they would (reasonably) assume that it won't be published.
> Also, e-mail is optional I believe, so there's no privacy
> issue there. I've looked through the Talkback data captured, and it
> only captures running processes, etc. not stuff that gives away personal
> data. If people are sending personal data in their comments, they
> should no better.
releasing the information without explicitly telling them would be
unethical, and quite possibly unlawful. if you put a bunch of warnings
on talkback that the data will be released to the public, nobody will use
it - people are paranoid already...
--
Michael
Heikki Toivonen
>> The talkback client asks for the user's email and for user comments.
>> Not sure what the former is used for, but the latter can be incredibly
There are several things where email helps:
* Search bugs by it (I can search for all talkback crashes reported by
me, for example)
* Send email to the user asking for more details
* The email address has domain information that may sometimes be helpful
in figuring out problems.
>> Unfortunately, the comments can often contain personal information as
>> well (eg the site the user was at, the user's name, etc). Such
>> information would need to be screened out.
>>
> What's the difference with putting such stuff in the Bugzilla then? The
> user should no full well that the information will be used to solve the
> problem. Also, e-mail is optional I believe, so there's no privacy
They know it will be used to solve the problems. But nowhere do we say
that the information they enter will be posted publicly. Not everyone
wants that to happen, even if they are willing to submit the talkback
report, and we shouldn't require them to.
--
Heikki Toivonen
Boris Zbarsky
> What's the difference with putting such stuff in the Bugzilla then?
The user knows that the information is going into a public bug database
that anyone in the world has access to. With talkback, there is no
obvious way to see that that is the case.
> I've looked through the Talkback data captured, and it
> only captures running processes, etc. not stuff that gives away personal
> data.
I think something like "I clicked on this thumbnail on this adult site"
is pretty personal data....
> If people are sending personal data in their comments, they
> should no better.
Yeah. They should provide no steps to reproduce, because they should
know better. They should not provide an email, so we won't accidentally
contact them and ask for more information. No, sirree.
The idea here is that people should feel secure in providing the
information necessary to fix the bug without that information being
distributed to the world at large in a way that can be associated with
them. Yeah, we could collect no information whatsoever, disable the
comment field, and just send back the stack. But that would be a lot
less useful.
Gervase Markham
> well (eg the site the user was at, the user's name, etc). Such
> information would need to be screened out.
More seriously, I believe that the stack dump itself, or associated
memory dumps (I'm a bit hazy on exactly what talkback collects) can
contain the values of parameters passed to functions, which could
include personal information like passwords.
Gerv
ralph
> Exposing talkback to the entire world is a hard problem
What about the following:
1. Pick only TBs that includes the user's email address.
Email the user with an email that includes the parts of
their TB that might contain personal info. Ask them to
scan the data and reply if they want Netscape to delete
the TB, or if, conversely, they are happy for it to be
copied to a restricted section of Bugzilla.
2. Only make the TB data available on a limited basis, eg
to those with a Bugzilla account with a TB privilege.
3. Allow for anyone who does access the TB data to delete
a TB (because they conclude it contains sensitive data).
--
ralph
Gervase Markham
> Email the user with an email that includes the parts of
> their TB that might contain personal info.
This act alone would cause a massive drop in the number of submitted
Talkbacks. If people know that they are going to get hassled with email,
they won't submit.
Gerv
ralph
Gerv, I don't think you thought this through.
1. There would be no massive drop.
For starters, no one would behave differently at first
because they would not be aware they are going to get
an email. You could easily try the system I suggest by
manually emailing a dozen people to see how it goes.
If the results suggest that the nightmare scenario you
talk of would come to pass, well, don't implement the
system.
Secondly, I don't see how a 'massive' drop could ever
happen no matter how badly people react. What % of TBs
even have an email? If there was less than a massive
% of TBs having an email address, you couldn't have a
massive drop no matter how badly you implemented the
system I suggested.
Thirdly, if someone who would normally provide an
email address decided they didn't want to receive
email, wouldn't they just omit the email address?
What sort of irrational lunkheads currently provide
TBs complete with email addys but would suddenly
decide they would abandon posting TBs entirely?
2. There's no hassle.
Why would people who provide an optional email address
freak out if they received an email?
Especially just one, and one that is specifically
designed to enhance the value of the TB they spent
time generating?
--
ralph
Michael Lefevre
> Gervase Markham wrote:
>>> 1. Pick only TBs that includes the user's email address.
>>> Email the user with an email that includes the parts of
>>> their TB that might contain personal info.
>>
>> This act alone would cause a massive drop in the number of
> > submitted Talkbacks. If people know that they are going to
> > get hassled with email, they won't submit.
>
> Gerv, I don't think you thought this through.
>
> 1. There would be no massive drop.
well that's your guess...
> For starters, no one would behave differently at first
> because they would not be aware they are going to get
> an email.
agreed.
> Thirdly, if someone who would normally provide an
> email address decided they didn't want to receive
> email, wouldn't they just omit the email address?
too late by then - assuming they didn't know it was optional in the first
place, they will at this point think that you're using their email
against their will...
> What sort of irrational lunkheads currently provide
> TBs complete with email addys but would suddenly
> decide they would abandon posting TBs entirely?
the same kind of irrational lunkheads that use software which is provided
for testing only, and then turn up in developer newsgroups asking
questions which are answered in the FAQ and/or release notes. they far
outnumber the people that will actually think this stuff through. if
we're stuck with them using mozilla, may as well try and get some useful
info out of them via talkback... if we weren't trying to get talkback
from the lunkheads, then it'd make sense to get rid of talkback unless
it's explicitly enabled...
> Why would people who provide an optional email address
> freak out if they received an email?
because they weren't expecting it. I'm sure lots of them would be
jumping to hurl abuse at netscape and/or reporting the emails with
spamcop...
> Especially just one,
"this is a one time mailing. this is not spam"... I'm not saying it's
true, but by the time they've got the email, you've already lost their
trust...
> and one that is specifically
> designed to enhance the value of the TB they spent
> time generating?
you're thinking about this too logically. if people get what they
believe is an unsolicited email, they will freak out. many (most?)
people already distrust talkback - if anything's going to change, it has
to persuade them that netscape/AOL/talkback are good things, not evil
snooping, spamming things...
--
Michael
Gervase Markham
> happen no matter how badly people react. What % of TBs
> even have an email? If there was less than a massive
> % of TBs having an email address, you couldn't have a
> massive drop no matter how badly you implemented the
> system I suggested.
You can't have it both ways. If only a few TBs have an email, then the
chances are that a particular one a person wanted for a bug wouldn't be
available.
> Thirdly, if someone who would normally provide an
> email address decided they didn't want to receive
> email, wouldn't they just omit the email address?
> What sort of irrational lunkheads currently provide
> TBs complete with email addys but would suddenly
> decide they would abandon posting TBs entirely?
If I got an email asking "Can I please make your data public", I would
think "How dumb are these guys to not add a checkbox to the Talkback UI
for that?" And then I would think "I have no idea what's in that data I
sent a week ago - No."
There's also the factor that someone inside Netscape (as that's where
the TB servers are) has to write a system to send out the emails, and
either someone has to take the time to manually read the responses, and
mark each talkback "public" or not as appropriate, or you have to write
a smart system which reads the emails for you. This alone sinks the
scheme - no-one has that sort of time, particularly as Shiva is working
on making some TB data available already.
Gerv
ralph
>>Gervase Markham wrote:
>>>>1. Pick only TBs that includes the user's email address.
>>>> Email the user with an email that includes the parts of
>>>> their TB that might contain personal info.
>>>
>>>This act alone would cause a massive drop in the number of
>>>submitted Talkbacks. If people know that they are going to
>>>get hassled with email, they won't submit.
>>
>
> well that's your guess...
I'll grant that I made my point in an interesting way,
but my statement was carefully written and was not a
guess. (Reread my first two subpoints.)
Gerv, on the other hand, phrased a guess as if it were
a fact. (Which is what prompted me to be unequivocal
in response.)
>> Thirdly, if someone who would normally provide an
>> email address decided they didn't want to receive
>> email, wouldn't they just omit the email address?
>
> too late by then - assuming they didn't know it was
> optional in the first place, they will at this point
> think that you're using their email against their will...
So we're now talking about the subset of people who are
happy to fill out a TB form, and in doing so, to give an
email address, but not to note that it was optional, and
to then respond to any email to that address in relation
to the TB as using their email against their will, and
to then kick up a big stink about that. How big a subset
do you think this is? Far more importantly, how big a
subset do you KNOW that this is?
> you're thinking about this too logically.
Logic is excellent in its domain.
I was able to conclude that there would be no massive
drop if one was to test the system by emailing 10 people.
Even if all 10 people had a problem, that would still
not translate to a massive drop. Is that too logical?
As for intuition, I'm a marketing guy that's analyzed
the results of millions of emails (my clients have
millions of customers). I have some insight in to how
consumers respond to emails.
As for being overly sure of one's thinking, I advocate
always testing assumptions. They're often wrong.
> if people get what they believe is an unsolicited email,
> they will freak out.
You talk as if it's impossible to come up with a TB
related email that won't freak people out. Indeed you
talk as if you KNOW that this is the case. Where did
you get your data? Can I see it?
> many (most?) people already distrust talkback -
The only people that matter here are the ones that choose
to fill out the TB and provide an email address. Are you
saying that many (most?) of these people distrust TB?
Where did you get this data? Can I see it?
--
ralph
ralph
> ... If only a few TBs have an email
then you can't have a massive drop, no matter what one
does. (Which was my point.)
Can anyone answer what % of TBs has an email address?
> [if the number of TB's with email addys is high enough
> to be useful, then it's high enough to be bad news to
> piss those TBers off]
Of course.
My response was and remains that, presuming the % of TBers
is high enough to be interesting, you test against a small
number, to see if your assumptions about the reaction of
TBers is valid.
> If I got an email asking "Can I please make your data
> public", I would think "How dumb are these guys to not
> add a checkbox to the Talkback UI for that?" And then
> I would think "I have no idea what's in that data I
> sent a week ago - No."
Right. But that's not remotely close to what I suggested.
Here's the sort of thing I was suggesting:
Thankyou for the Netscape Talkback (crash) data you
recently sent to us. We appreciate the feedback!
Engineers at Mozilla.org (who help us create Netscape)
would also like to see this crash data. The relevant
data is shown below. Please review it then hit reply
and send if it's OK for us to forward the data.
> There's also the factor that someone inside Netscape
> (as that's where the TB servers are) has to write a
> system to send out the emails
Given how much time is being spent on this manually,
I find it hard to believe that this would be a show-stopper.
> and either someone has to take the time to manually
> read the responses, and mark each talkback "public"
> or not as appropriate, or you have to write a smart
> system which reads the emails for you.
No. If an email arrives, its corresponding TB is OK
to go to Mozilla. Very simple.
--
ralph
ralph
> Unfortunately, the comments can often contain personal information as
> well (eg the site the user was at, the user's name, etc). Such
> information would need to be screened out.
Ask user to OK passing of TB to m.o
Put TBs in bugzilla but limit access.
Simple. And might work.
--
ralph
Benjamin Smedberg
> personal data. We can't make everyone sign agreements. And presumably
> this guy has official academic accreditation and so on.
OK, here's what I would like, and I think it's technically possible. I
want access to the TB data that I submit, i.e.: I submit a TB incident,
but the stacktrace is unusable because it doesn't have symbols. If TB
could do it's magic and give me the symbols for my own TB stacks, that
would save quite a bit of time. I could ask bug submitters for their own
stack, bypassing the private NS problem altogether.
Chris O'Connor
talkback messages over the years and I would like to get an e-mail if
what I could say/provide be of more help. The idea that a person would
spend time on a talkback and then NOT want to get a response from a
developer that says "thanks for the talk back - could you inform us more
about what happened with the browser? I would love to hear that my
input makes a difference.
L. David Baron
Here's a possible solution that I haven't seen in this thread (although
I haven't read every message, I don't think):
We could create a server through which talkback reports could be
accessed. Users would be able to register at this server (by filling
out a form that sends a password to their email address, which could
later be changed, just like bugzilla registration). Registered users
would be able to (in priority order of how important I think these
features are to implement):
* see their own talkback reports (based on matching the email address
in the reports to the email in the registration)
* make all their talkback reports public by default
* make individual talkback reports public
(Then there's the question of what information would be available in a
talkback report that was made public by the user who submitted it.)
All users (or all registered users?) would then be able to search the
talkback reports that had been made public.
-David
--
L. David Baron <URL: http://dbaron.org/ >
ralph
> TBers could do any of:
>
> * see their own talkback reports
> * make individual talkback reports public
For various reasons, if anything like this is to be done,
I suggest restricting who gets to see the TBs (you suggest
the same yourself); and to stick to language that reflects
that. So, replace "public" with "available to mozilla.org".
My point is that the issue here is just to have TBers OK
making their TB data available to m.o, not to do something
that sounds/is as drastic as making their TB data fully public.
An essential element of your suggestion is to give TBers some
self-service way to make their TBs available to m.o, instead
of having Netscape employees filter them manually and/or en
masse. Some problems with this are:
1. If you are going to let a TBer see a TB not yet available
to m.o, someone would have to write some software, and the
software would need to be installed on a Netscape server.
(One could/should start simple by manually constructing
and sending a handful of emails in lieu of a real system.
This would allow testing of peoples' reaction to and use
of the system, an issue which the next point expands on.)
2. Unless the TBer is the developer that wants the TB data,
you have to get in touch with the TBer to get their OK.
Gerv and others have suggested (in other posts in this
thread) that such unsolicited contact would be the kiss
of death for the whole TB stream.
As explained in my responses, I don't think Gerv et al
is right, and it would take relatively little effort to
non-destructively test this anyway (via some emails).
But the nature of the email that needs to be sent (it
is "unsolicited", makes life more complicated for the
TBer, and concerns privacy) means that it would need
to be written and tested with appropriate care.
--
ralph