--047d7b10c9d1519df5051f6ae811
Content-Type: text/plain; charset=UTF-8

I often see things like these bugs:

Slow motion support for camera:
https://bugzilla.mozilla.org/show_bug.cgi?id=1190244

Scene modes for camera: https://bugzilla.mozilla.org/show_bug.cgi?id=1187690

These are features, with patches, that are blocked on UX input - sometimes
for months. After sitting for a while, it's quite likely that the patches
no longer apply.

However, the problem isn't really that these are blocked on UX input. Even
if UX gives input, and designs full specs for the feature, we don't have
full engineering support, QA support and we don't have any release
stability wiggle-room to properly support the feature.

In both of these cases, the device in question isn't actually targeted for
any release - it's the Foxfooding device, and another device that only will
have community builds.

We end up stuck in a position where we cannot experiment and iterate on
features, even in devices we're not actually shipping in any markets.

I propose we use system preferences and the developer menu in the Settings
app more liberally for things like this - adding feature killswitches to
ensure features are not only turned off in release configurations, but
possibly also ensure that the code itself is not included, so as not to
risk release stability.

I don't know that killswitches are the right answer. Maybe add-ons are, at
least for the front-end parts?

Whatever the solution, we need to find a way to enable feature development
with as few restrictions as possible, without risking overall stability.
Got any ideas on how to do that?

--047d7b10c9d1519df5051f6ae811
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I often see things like these bugs:<br><br>Slow motio=
n support for camera: <a href=3D"https://bugzilla.mozilla.org/show_bug.cgi?=
id=3D1190244">https://bugzilla.mozilla.org/show_bug.cgi?id=3D1190244</a><br=
><br></div><div>Scene modes for camera: <a href=3D"https://bugzilla.mozilla=
..org/show_bug.cgi?id=3D1187690">https://bugzilla.mozilla.org/show_bug.cgi?i=
d=3D1187690</a><br><br></div><div>These are features, with patches, that ar=
e blocked on UX input - sometimes for months. After sitting for a while, it=
&#39;s quite likely that the patches no longer apply.<br><br>However, the p=
roblem isn&#39;t really that these are blocked on UX input. Even if UX give=
s input, and designs full specs for the feature, we don&#39;t have full eng=
ineering support, QA support and we don&#39;t have any release stability wi=
ggle-room to properly support the feature.<br><br></div><div>In both of the=
se cases, the device in question isn&#39;t actually targeted for any releas=
e - it&#39;s the Foxfooding device, and another device that only will have =
community builds.<br></div><div><br></div><div>We end up stuck in a positio=
n where we cannot experiment and iterate on features, even in devices we&#3=
9;re not actually shipping in any markets.<br><br></div><div>I propose we u=
se system preferences and the developer menu in the Settings app more liber=
ally for things like this - adding feature killswitches to ensure features =
are not only turned off in release configurations, but possibly also ensure=
 that the code itself is not included, so as not to risk release stability.=
<br><br></div><div>I don&#39;t know that killswitches are the right answer.=
 Maybe add-ons are, at least for the front-end parts?<br><br>Whatever the s=
olution, we need to find a way to enable feature development with as few re=
strictions as possible, without risking overall stability. Got any ideas on=
 how to do that?<br></div></div>

--047d7b10c9d1519df5051f6ae811--

On 09/10/2015 04:01 PM, Dietrich Ayala wrote:
> Whatever the solution, we need to find a way to enable feature
> development with as few restrictions as possible, without risking
> overall stability. Got any ideas on how to do that?

Hire more UX people so the ones we have aren't overloaded with work? :)

- Jim

--047d7b3a9540941ba2051f6b5875
Content-Type: text/plain; charset=UTF-8

Hiring more designers is not a solution. Blocked on design is only a
symptom of a much larger issue, as I discussed in the initial email :)


On Thu, Sep 10, 2015 at 2:18 PM Jim Porter <jporter@mozilla.com> wrote:

> On 09/10/2015 04:01 PM, Dietrich Ayala wrote:
> > Whatever the solution, we need to find a way to enable feature
> > development with as few restrictions as possible, without risking
> > overall stability. Got any ideas on how to do that?
>
> Hire more UX people so the ones we have aren't overloaded with work? :)
>
> - Jim
> _______________________________________________
> dev-gaia mailing list
> dev-gaia@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
>

--047d7b3a9540941ba2051f6b5875
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hiring more designers is not a solution. Blocked on d=
esign is only a symptom of a much larger issue, as I discussed in the initi=
al email :)<br><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr">On Thu, Sep 10, 2015 at 2:18 PM Jim Porter &lt;<a href=3D"mailto:jporte=
r@mozilla.com">jporter@mozilla.com</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">On 09/10/2015 04:01 PM, Dietrich Ayala wrote:<br>
&gt; Whatever the solution, we need to find a way to enable feature<br>
&gt; development with as few restrictions as possible, without risking<br>
&gt; overall stability. Got any ideas on how to do that?<br>
<br>
Hire more UX people so the ones we have aren&#39;t overloaded with work? :)=
<br>
<br>
- Jim<br>
_______________________________________________<br>
dev-gaia mailing list<br>
<a href=3D"mailto:dev-gaia@lists.mozilla.org" target=3D"_blank">dev-gaia@li=
sts.mozilla.org</a><br>
<a href=3D"https://lists.mozilla.org/listinfo/dev-gaia" rel=3D"noreferrer" =
target=3D"_blank">https://lists.mozilla.org/listinfo/dev-gaia</a><br>
</blockquote></div>

--047d7b3a9540941ba2051f6b5875--

--001a11359fc0f9da68051f6ca352
Content-Type: text/plain; charset=UTF-8

Hrm.  I thought I sent out an email about this before.

I think :
1) we do need more UX folks as well as QA folks.  Not that Apple should be
the role model here, having said that they have a 2 to 1 UX to Dev ratio
and those UX/UR folks do a lot of prototyping ahead of time before the spec
is handed off to Dev.  2 Dev to 1 QA is the Dev to QA ratio there.
This is a rough estimate that was once told to me by a VP of engineering at
least 5 years ago.

2) Product ( PM/UX/UR ) in general should be one version ahead of Dev.
Prototyping the next version in what it could look like, the feature set,
and talking to Dev in which features might slip; what things are
technically feasible, etc.  Dev should also be allowed to do a little bit
of upfront research to make sure they are ready for the tasks / not just
wrapping up on the current version towards the end of the cycle and this
should be accounted for in the schedule...

These are just my opinions though.



On Thu, Sep 10, 2015 at 2:33 PM, Dietrich Ayala <autonome@gmail.com> wrote:

> Hiring more designers is not a solution. Blocked on design is only a
> symptom of a much larger issue, as I discussed in the initial email :)
>
>
> On Thu, Sep 10, 2015 at 2:18 PM Jim Porter <jporter@mozilla.com> wrote:
>
>> On 09/10/2015 04:01 PM, Dietrich Ayala wrote:
>> > Whatever the solution, we need to find a way to enable feature
>> > development with as few restrictions as possible, without risking
>> > overall stability. Got any ideas on how to do that?
>>
>> Hire more UX people so the ones we have aren't overloaded with work? :)
>>
>> - Jim
>> _______________________________________________
>> dev-gaia mailing list
>> dev-gaia@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-gaia
>>
>
> _______________________________________________
> dev-gaia mailing list
> dev-gaia@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
>
>

--001a11359fc0f9da68051f6ca352
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hrm.=C2=A0 I thought I sent out an email ab=
out this before.=C2=A0 <br><br></div>I think :<br></div>1) we do need more =
UX folks as well as QA folks.=C2=A0 Not that Apple should be the role model=
 here, having said that they have a 2 to 1 UX to Dev ratio and those UX/UR =
folks do a lot of prototyping ahead of time before the spec is handed off t=
o Dev.=C2=A0 2 Dev to 1 QA is the Dev to QA ratio there.<br></div>This is a=
 rough estimate that was once told to me by a VP of engineering at least 5 =
years ago.<br><br><div>2) Product ( PM/UX/UR ) in general should be one ver=
sion ahead of Dev.=C2=A0 Prototyping the next version in what it could look=
 like, the feature set, and talking to Dev in which features might slip; wh=
at things are technically feasible, etc.=C2=A0 Dev should also be allowed t=
o do a little bit of upfront research to make sure they are ready for the t=
asks / not just wrapping up on the current version towards the end of the c=
ycle and this should be accounted for in the schedule...<br><br></div><div>=
These are just my opinions though.<br></div><div><br><br></div></div><div c=
lass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Sep 10, 2015 at=
 2:33 PM, Dietrich Ayala <span dir=3D"ltr">&lt;<a href=3D"mailto:autonome@g=
mail.com" target=3D"_blank">autonome@gmail.com</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Hiring more designers is =
not a solution. Blocked on design is only a symptom of a much larger issue,=
 as I discussed in the initial email :)<br><br></div></div><div class=3D"HO=
EnZb"><div class=3D"h5"><br><div class=3D"gmail_quote"><div dir=3D"ltr">On =
Thu, Sep 10, 2015 at 2:18 PM Jim Porter &lt;<a href=3D"mailto:jporter@mozil=
la.com" target=3D"_blank">jporter@mozilla.com</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">On 09/10/2015 04:01 PM, Dietrich Ayala wrote:<br>
&gt; Whatever the solution, we need to find a way to enable feature<br>
&gt; development with as few restrictions as possible, without risking<br>
&gt; overall stability. Got any ideas on how to do that?<br>
<br>
Hire more UX people so the ones we have aren&#39;t overloaded with work? :)=
<br>
<br>
- Jim<br>
_______________________________________________<br>
dev-gaia mailing list<br>
<a href=3D"mailto:dev-gaia@lists.mozilla.org" target=3D"_blank">dev-gaia@li=
sts.mozilla.org</a><br>
<a href=3D"https://lists.mozilla.org/listinfo/dev-gaia" rel=3D"noreferrer" =
target=3D"_blank">https://lists.mozilla.org/listinfo/dev-gaia</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
dev-gaia mailing list<br>
<a href=3D"mailto:dev-gaia@lists.mozilla.org">dev-gaia@lists.mozilla.org</a=
><br>
<a href=3D"https://lists.mozilla.org/listinfo/dev-gaia" rel=3D"noreferrer" =
target=3D"_blank">https://lists.mozilla.org/listinfo/dev-gaia</a><br>
<br></blockquote></div><br></div>

--001a11359fc0f9da68051f6ca352--

On 09/10/2015 04:33 PM, Dietrich Ayala wrote:
> Hiring more designers is not a solution. Blocked on design is only a
> symptom of a much larger issue, as I discussed in the initial email :)

The same rule generalizes to all of your issues, though. You
specifically called out a lack of UX, engineering, and QA support. If
you want *more* support in any of those areas, then we either need more
people or fewer features.

I don't think feature flags are a good solution to this problem, and we
should strive to avoid them, especially in Gaia-land where we have
significantly longer between releases to work on a feature. I can see
some logic for putting Gecko code behind feature flags, since release
cycles are so much shorter (and many of the Gecko features are more
complex in my experience). I don't see any reason why the bugs you
posted would need to be hidden behind a feature flag. Neither of them
seem particularly complex to implement, so I doubt we'd need for them to
bake on master for very long to work out all the kinks.

Feature flags are a great way to add extra complexity to apps
(especially in the scaffolding required to support branching in code).
They hamper testability, maintainability, and security. To quote an
article[1] on the subject, feature flags are "... in many ways a step
back to the way that people built software 20+ years ago when we didn’t
have reliable and easy to use code management systems."

There may be some advantages in general to using add-ons to experiment
with new features, since add-ons work more like local patches and aren't
in-tree. I've done as much in my Thunderbird work, and it's functionally
very similar to working in a branch. However, I don't think they'd be
much help with the bugs you mentioned, which don't seem to need much in
the way of experimentation.

- Jim

[1]
http://swreflections.blogspot.com/2014/08/feature-toggles-are-one-of-worst-kinds.html

--001a113deb3839cccc051f6dc93b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'm actually suggesting *less* UX, QA and release support. We don't want or
need it for experimental features. Right now, there's no way to land
something and iterate on it with it not being targeted for a release.

The bugs I referenced cannot be done solely as add-ons and also have sat
for months without being landed, and if they do land, they'll only work on
non-productized devices.

I do agree with you that feature flags for *users* are not great - but
that's not at all what we're talking about here.





On Thu, Sep 10, 2015 at 5:00 PM Jim Porter <jporter@mozilla.com> wrote:

> On 09/10/2015 04:33 PM, Dietrich Ayala wrote:
> > Hiring more designers is not a solution. Blocked on design is only a
> > symptom of a much larger issue, as I discussed in the initial email :)
>
> The same rule generalizes to all of your issues, though. You
> specifically called out a lack of UX, engineering, and QA support. If
> you want *more* support in any of those areas, then we either need more
> people or fewer features.
>
> I don't think feature flags are a good solution to this problem, and we
> should strive to avoid them, especially in Gaia-land where we have
> significantly longer between releases to work on a feature. I can see
> some logic for putting Gecko code behind feature flags, since release
> cycles are so much shorter (and many of the Gecko features are more
> complex in my experience). I don't see any reason why the bugs you
> posted would need to be hidden behind a feature flag. Neither of them
> seem particularly complex to implement, so I doubt we'd need for them to
> bake on master for very long to work out all the kinks.
>
> Feature flags are a great way to add extra complexity to apps
> (especially in the scaffolding required to support branching in code).
> They hamper testability, maintainability, and security. To quote an
> article[1] on the subject, feature flags are "... in many ways a step
> back to the way that people built software 20+ years ago when we didn=E2=
=80=99t
> have reliable and easy to use code management systems."
>
> There may be some advantages in general to using add-ons to experiment
> with new features, since add-ons work more like local patches and aren't
> in-tree. I've done as much in my Thunderbird work, and it's functionally
> very similar to working in a branch. However, I don't think they'd be
> much help with the bugs you mentioned, which don't seem to need much in
> the way of experimentation.
>
> - Jim
>
> [1]
>
> http://swreflections.blogspot.com/2014/08/feature-toggles-are-one-of-wors=
t-kinds.html
> _______________________________________________
> dev-gaia mailing list
> dev-gaia@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
>

--001a113deb3839cccc051f6dc93b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>I&#39;m actually suggesting *less* UX, QA and re=
lease support. We don&#39;t want or need it for experimental features. Righ=
t now, there&#39;s no way to land something and iterate on it with it not b=
eing targeted for a release.<br><br></div>The bugs I referenced cannot be d=
one solely as add-ons and also have sat for months without being landed, an=
d if they do land, they&#39;ll only work on non-productized devices.<br><br=
></div><div>I do agree with you that feature flags for *users* are not grea=
t - but that&#39;s not at all what we&#39;re talking about here.<br></div><=
div><br></div><br><div><div><div><div><br><br></div></div></div></div></div=
><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Sep 10, 2015 at 5:=
00 PM Jim Porter &lt;<a href=3D"mailto:jporter@mozilla.com">jporter@mozilla=
..com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/10/2015 0=
4:33 PM, Dietrich Ayala wrote:<br>
&gt; Hiring more designers is not a solution. Blocked on design is only a<b=
r>
&gt; symptom of a much larger issue, as I discussed in the initial email :)=
<br>
<br>
The same rule generalizes to all of your issues, though. You<br>
specifically called out a lack of UX, engineering, and QA support. If<br>
you want *more* support in any of those areas, then we either need more<br>
people or fewer features.<br>
<br>
I don&#39;t think feature flags are a good solution to this problem, and we=
<br>
should strive to avoid them, especially in Gaia-land where we have<br>
significantly longer between releases to work on a feature. I can see<br>
some logic for putting Gecko code behind feature flags, since release<br>
cycles are so much shorter (and many of the Gecko features are more<br>
complex in my experience). I don&#39;t see any reason why the bugs you<br>
posted would need to be hidden behind a feature flag. Neither of them<br>
seem particularly complex to implement, so I doubt we&#39;d need for them t=
o<br>
bake on master for very long to work out all the kinks.<br>
<br>
Feature flags are a great way to add extra complexity to apps<br>
(especially in the scaffolding required to support branching in code).<br>
They hamper testability, maintainability, and security. To quote an<br>
article[1] on the subject, feature flags are &quot;... in many ways a step<=
br>
back to the way that people built software 20+ years ago when we didn=E2=80=
=99t<br>
have reliable and easy to use code management systems.&quot;<br>
<br>
There may be some advantages in general to using add-ons to experiment<br>
with new features, since add-ons work more like local patches and aren&#39;=
t<br>
in-tree. I&#39;ve done as much in my Thunderbird work, and it&#39;s functio=
nally<br>
very similar to working in a branch. However, I don&#39;t think they&#39;d =
be<br>
much help with the bugs you mentioned, which don&#39;t seem to need much in=
<br>
the way of experimentation.<br>
<br>
- Jim<br>
<br>
[1]<br>
<a href=3D"http://swreflections.blogspot.com/2014/08/feature-toggles-are-on=
e-of-worst-kinds.html" rel=3D"noreferrer" target=3D"_blank">http://swreflec=
tions.blogspot.com/2014/08/feature-toggles-are-one-of-worst-kinds.html</a><=
br>
_______________________________________________<br>
dev-gaia mailing list<br>
<a href=3D"mailto:dev-gaia@lists.mozilla.org" target=3D"_blank">dev-gaia@li=
sts.mozilla.org</a><br>
<a href=3D"https://lists.mozilla.org/listinfo/dev-gaia" rel=3D"noreferrer" =
target=3D"_blank">https://lists.mozilla.org/listinfo/dev-gaia</a><br>
</blockquote></div>

--001a113deb3839cccc051f6dc93b--

--001a113f39f0fa7789051f6e0822
Content-Type: text/plain; charset=UTF-8

You've described an ideal version of a typical software development cycle.
(Or not ideal nor typical, depending on where we've all worked before!)

But we're not in that situation.

We're in a high-stakes gambit against entrenched incumbents who can
out-hire us 1000 to 1 for far longer than we can attempt to keep up.

We cannot compete symmetrically against the incumbents using their methods.
We must optimize for our unique strengths: Maximize participation vectors
and remove as many barriers to experimentation as possible, to enable
innovation to occur at scale.

I'm asking about ways to accelerate feature development in ways that allow
more people to participate and more non-release experimentation to occur in
the project... and doing it in a way that minimizes the impact on our
product release cycle.

Maybe that is add-ons for features. But for other features, add-ons might
not be a feasible solution.


On Thu, Sep 10, 2015 at 4:05 PM Naoki Hirata <nhirata@mozilla.com> wrote:

> Hrm.  I thought I sent out an email about this before.
>
> I think :
> 1) we do need more UX folks as well as QA folks.  Not that Apple should be
> the role model here, having said that they have a 2 to 1 UX to Dev ratio
> and those UX/UR folks do a lot of prototyping ahead of time before the spec
> is handed off to Dev.  2 Dev to 1 QA is the Dev to QA ratio there.
> This is a rough estimate that was once told to me by a VP of engineering
> at least 5 years ago.
>
> 2) Product ( PM/UX/UR ) in general should be one version ahead of Dev.
> Prototyping the next version in what it could look like, the feature set,
> and talking to Dev in which features might slip; what things are
> technically feasible, etc.  Dev should also be allowed to do a little bit
> of upfront research to make sure they are ready for the tasks / not just
> wrapping up on the current version towards the end of the cycle and this
> should be accounted for in the schedule...
>
> These are just my opinions though.
>
>
>
> On Thu, Sep 10, 2015 at 2:33 PM, Dietrich Ayala <autonome@gmail.com>
> wrote:
>
>> Hiring more designers is not a solution. Blocked on design is only a
>> symptom of a much larger issue, as I discussed in the initial email :)
>>
>>
>> On Thu, Sep 10, 2015 at 2:18 PM Jim Porter <jporter@mozilla.com> wrote:
>>
>>> On 09/10/2015 04:01 PM, Dietrich Ayala wrote:
>>> > Whatever the solution, we need to find a way to enable feature
>>> > development with as few restrictions as possible, without risking
>>> > overall stability. Got any ideas on how to do that?
>>>
>>> Hire more UX people so the ones we have aren't overloaded with work? :)
>>>
>>> - Jim
>>> _______________________________________________
>>> dev-gaia mailing list
>>> dev-gaia@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-gaia
>>>
>>
>> _______________________________________________
>> dev-gaia mailing list
>> dev-gaia@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-gaia
>>
>>
>

--001a113f39f0fa7789051f6e0822
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>You&#39;ve described an ideal version of a =
typical software development cycle. (Or not ideal nor typical, depending on=
 where we&#39;ve all worked before!)<br><br>But we&#39;re not in that situa=
tion.<br><br>We&#39;re in a high-stakes gambit against entrenched incumbent=
s who can out-hire us 1000 to 1 for far longer than we can attempt to keep =
up.<br></div><br></div>We cannot compete symmetrically against the incumben=
ts using their methods. We must optimize for our unique strengths: Maximize=
 participation vectors and remove as many barriers to experimentation as po=
ssible, to enable innovation to occur at scale.<br><br>I&#39;m asking about=
 ways to accelerate feature development in ways that allow more people to p=
articipate and more non-release experimentation to occur in the project... =
and doing it in a way that minimizes the impact on our product release cycl=
e.<br><br></div><div>Maybe that is add-ons for features. But for other feat=
ures, add-ons might not be a feasible solution.<br></div><div><br><br></div=
><div><div><div><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Se=
p 10, 2015 at 4:05 PM Naoki Hirata &lt;<a href=3D"mailto:nhirata@mozilla.co=
m">nhirata@mozilla.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div><div><div>Hrm.=C2=A0 I thought I sent out an email=
 about this before.=C2=A0 <br><br></div>I think :<br></div>1) we do need mo=
re UX folks as well as QA folks.=C2=A0 Not that Apple should be the role mo=
del here, having said that they have a 2 to 1 UX to Dev ratio and those UX/=
UR folks do a lot of prototyping ahead of time before the spec is handed of=
f to Dev.=C2=A0 2 Dev to 1 QA is the Dev to QA ratio there.<br></div>This i=
s a rough estimate that was once told to me by a VP of engineering at least=
 5 years ago.<br><br><div>2) Product ( PM/UX/UR ) in general should be one =
version ahead of Dev.=C2=A0 Prototyping the next version in what it could l=
ook like, the feature set, and talking to Dev in which features might slip;=
 what things are technically feasible, etc.=C2=A0 Dev should also be allowe=
d to do a little bit of upfront research to make sure they are ready for th=
e tasks / not just wrapping up on the current version towards the end of th=
e cycle and this should be accounted for in the schedule...<br><br></div><d=
iv>These are just my opinions though.<br></div><div><br><br></div></div><di=
v class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Sep 10, 2015=
 at 2:33 PM, Dietrich Ayala <span dir=3D"ltr">&lt;<a href=3D"mailto:autonom=
e@gmail.com" target=3D"_blank">autonome@gmail.com</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Hiring more designers =
is not a solution. Blocked on design is only a symptom of a much larger iss=
ue, as I discussed in the initial email :)<br><br></div></div><div><div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Sep 10, 2015 at 2:18 P=
M Jim Porter &lt;<a href=3D"mailto:jporter@mozilla.com" target=3D"_blank">j=
porter@mozilla.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">O=
n 09/10/2015 04:01 PM, Dietrich Ayala wrote:<br>
&gt; Whatever the solution, we need to find a way to enable feature<br>
&gt; development with as few restrictions as possible, without risking<br>
&gt; overall stability. Got any ideas on how to do that?<br>
<br>
Hire more UX people so the ones we have aren&#39;t overloaded with work? :)=
<br>
<br>
- Jim<br>
_______________________________________________<br>
dev-gaia mailing list<br>
<a href=3D"mailto:dev-gaia@lists.mozilla.org" target=3D"_blank">dev-gaia@li=
sts.mozilla.org</a><br>
<a href=3D"https://lists.mozilla.org/listinfo/dev-gaia" rel=3D"noreferrer" =
target=3D"_blank">https://lists.mozilla.org/listinfo/dev-gaia</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
dev-gaia mailing list<br>
<a href=3D"mailto:dev-gaia@lists.mozilla.org" target=3D"_blank">dev-gaia@li=
sts.mozilla.org</a><br>
<a href=3D"https://lists.mozilla.org/listinfo/dev-gaia" rel=3D"noreferrer" =
target=3D"_blank">https://lists.mozilla.org/listinfo/dev-gaia</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div></div></div></div></div>

--001a113f39f0fa7789051f6e0822--

On 09/10/2015 07:27 PM, Dietrich Ayala wrote:
> I'm actually suggesting *less* UX, QA and release support. We don't want
> or need it for experimental features. Right now, there's no way to land
> something and iterate on it with it not being targeted for a release.

I don't think the features you described could really be called
"experimental". From looking at the patches, it seems like they're
relatively-simple features whose main challenge is in defining some good
UX for it.

At *some* point before a release that enabled a feature, UX would need
to decide how the feature should actually look. I don't think your
suggestion would result in less overall work for UX (or QA); it would
just put them into debt. Worse, it would mean additional work for
developers, since we'd have to create preliminary UX and then revise it
after the UX team has provided feedback.

> The bugs I referenced cannot be done solely as add-ons and also have sat
> for months without being landed, and if they do land, they'll only work
> on non-productized devices.

Are you sure? One of them requires a Gecko change, but I don't think UX
would care about a Gecko-only change. The other changes are just in the
camera app, and that should be doable in an add-on, right? If not, I'm
afraid I don't see much point to having add-ons in the first place if
they can't make simple changes like in these patches.

Granted, some of this could be the fault of the camera app making it
difficult to inject scripts as needed, but that's a problem we'd need to
address in our apps so that people can actually write useful add-ons.

> I do agree with you that feature flags for *users* are not great - but
> that's not at all what we're talking about here.

That's not what I'm talking about either. While feature flags are bad UX
(users shouldn't be inundated with needless choices), they're also a
particularly nasty form of technical debt. I'll re-link the article I
referenced last time, since it sums up my feelings pretty nicely:
<http://swreflections.blogspot.com/2014/08/feature-toggles-are-one-of-worst-kinds.html>.

- Jim

On 09/10/2015 07:45 PM, Dietrich Ayala wrote:
> You've described an ideal version of a typical software development
> cycle. (Or not ideal nor typical, depending on where we've all worked
> before!)
> 
> But we're not in that situation.
> 
> We're in a high-stakes gambit against entrenched incumbents who can
> out-hire us 1000 to 1 for far longer than we can attempt to keep up.

I don't think we're any smarter than Apple or Google people. If they
could produce software at the quality level they expect with fewer
workers, they would. There isn't some shortcut we can take to make our
labor more efficient than theirs. If we try to go faster, we'll
sacrifice quality (possibly in worse UX or less code
maintainability/testability).

Given the choice, I'd rather have a feature-light phone that works
really well than a feature-rich one with lots of bugs and bad UX.

> We cannot compete symmetrically against the incumbents using their
> methods. We must optimize for our unique strengths: Maximize
> participation vectors and remove as many barriers to experimentation as
> possible, to enable innovation to occur at scale.

I assume this means something like "make it easy to incorporate
volunteer labor into Firefox OS". In that case, I think it's even more
essential to have a big UX team that can respond quickly; I really don't
trust random volunteers to have a solid understanding of our UX goals.
Granted, this could mean empowering some of the more visually-oriented
developers with limited UX-powers, but that's not really much different
from replacing some developers with UXers.

> I'm asking about ways to accelerate feature development in ways that
> allow more people to participate and more non-release experimentation to
> occur in the project... and doing it in a way that minimizes the impact
> on our product release cycle.

Accelerating feature development in Firefox OS is probably the last
thing I'm interested in. Firefox OS (especially master) is just too
buggy for me. I'm happy using Firefox Nightly, since I've almost never
been bitten by a serious bug there, but every time I try Firefox OS
nightlies, some core feature is just completely broken. Perhaps it's not
a fair comparison, since we don't have a gaia-inbound branch, but
there's no reason that SMS should be broken on master, as you mentioned
in another thread. (Incidentally, SMS being broken was why I gave up
dogfooding the last time I tried several months ago.)

- Jim

--001a113ac3ac84193c051f732427
Content-Type: text/plain; charset=UTF-8

(retrying list posting, apologies if this reaches the list twice)

On Thu, Sep 10, 2015 at 11:01 PM, Dietrich Ayala <dietrich@mozilla.com>
wrote:

> adding feature killswitches to ensure features are not only turned off in
> release configurations, but possibly also ensure that the code itself is
> not included, so as not to risk release stability.
>

We had exactly this issue for Data Sync, and Sean landed just the thing for
this, last week! :) I think this is so fresh that it's not even on the wiki
yet, but here's how it works:

build/preprocessor.js
<https://github.com/mozilla-b2g/gaia/blob/df6624afb5d6960f00925f412d29c6c08db7b405/build/preprocessor.js#L74-L94>

You can call it from your app's build/build.js script, and then use IFDEF
tags in your html code, and include/exclude your js files and other
feature-specific resources. See Sean's WiP branch
<https://github.com/weilonge/gaia/commit/4ac77b1a85acf5b09fe8856235bfb2697167a82e>
for how we use it for enabling/disabling the "Firefox Sync" feature.

If the build flag for your feature is not set (ours is called FIREFOX_SYNC
as you can see there), the code will not end up in build_stage.


Cheers,
Michiel.

--001a113ac3ac84193c051f732427
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">(retrying list posting, apologies if this reaches the list=
 twice)<br><div><br><div>On Thu, Sep 10, 2015 at 11:01 PM, Dietrich Ayala <=
span dir=3D"ltr">&lt;<a href=3D"mailto:dietrich@mozilla.com" target=3D"_bla=
nk">dietrich@mozilla.com</a>&gt;</span> wrote:<div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div>adding
 feature killswitches to ensure features are not only turned off in=20
release configurations, but possibly also ensure that the code itself is
 not included, so as not to risk release stability.<span class=3D""><br></s=
pan></div></blockquote><br>We
 had exactly this issue for Data Sync, and Sean landed just the thing=20
for this, last week! :) I think this is so fresh that it&#39;s not even on=
=20
the wiki yet, but here&#39;s how it works:<br><br><a href=3D"https://github=
..com/mozilla-b2g/gaia/blob/df6624afb5d6960f00925f412d29c6c08db7b405/build/p=
reprocessor.js#L74-L94" target=3D"_blank">build/preprocessor.js</a><br><div=
 class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">You
 can call it from your app&#39;s build/build.js script, and then use IFDEF=
=20
tags in your html code, and include/exclude your js files and other=20
feature-specific resources. See <a href=3D"https://github.com/weilonge/gaia=
/commit/4ac77b1a85acf5b09fe8856235bfb2697167a82e" target=3D"_blank">Sean&#3=
9;s WiP branch</a> for how we use it for enabling/disabling the &quot;Firef=
ox Sync&quot; feature.<br><br></div><div class=3D"gmail_extra">If
 the build flag for your feature is not set (ours is called FIREFOX_SYNC
 as you can see there), the code will not end up in build_stage.<br></div><=
br><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Cheers,<=
br></div>Michiel.<div class=3D"gmail_extra"><br></div></div></div></div></d=
iv>

--001a113ac3ac84193c051f732427--

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--F8fFdac0lQcAIfAiLlqul2Agr83NDXlND
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 11/09/2015 02:45, Dietrich Ayala wrote:
> I'm asking about ways to accelerate feature development in ways that
> allow more people to participate and more non-release experimentation t=
o
> occur in the project... and doing it in a way that minimizes the impact=

> on our product release cycle.

Amen to that. Feature flags need not cover fragile, untested bits of
code that will eventually rot. If we're landing a feature behind a flag
we can ask for unit-tests, and even integration-tests to be in place
from day one so it gets a good measure of protection from changes
elsewhere in the code. This would be *great* for contributors; I've seen
multiple potential contributions being turned down because either we
couldn't get UX in place or we couldn't get it on the product roadmap.
That basically limits contribution to things that are already planned
for and with UX attached to them. Not an interesting proposition for
somebody who wants to start contributing because he has a valuable
feature idea, a specific requirement or just an itch to scratch.

 Gabriele



--F8fFdac0lQcAIfAiLlqul2Agr83NDXlND
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJV8ntPAAoJELfDtXDR2GV1iAUH/jljKVeaNtdZ5mqSFFLGQXP3
DU4qbzeTEd6qe7pFi7LrZfLzI9OL55ejVnrWAVXegvSK7htCLHY7MmTCpB0gOZZ4
u2w8E0vK5laimVipIAxkaw4BtlI5T3bNE0lLzVTA1QI/ovg0RwnHqnhPc1RnxnBX
ZBHk9UFVynf2cKzZgP6k3P6rSj7oDP9WCNWyeKjDDSi67BoWn3caMWsGDuDAcpYw
GFvyR9+2BhOWwTE81lSbN2f3A04sTDCGQNTTgpfGTi3Qaw+2KNQD/UDxy7kmAg7N
33/EsN/i0n46OM6O0l0mbJa9qIs9256hLopPR4G6kKfVnKJsG+uEydtD2xSXfw4=
=fMAz
-----END PGP SIGNATURE-----

--F8fFdac0lQcAIfAiLlqul2Agr83NDXlND--

--001a1142e19efef1da051f7b94d3
Content-Type: text/plain; charset=UTF-8

I agree with Jim Porter.  I think we should clean up a lot of the things
that we currently have; there are so many back log bugs in the system and
not all of them are polish.

I agree with Gabriele in that untested code will bitrot.  If there's addons
for experiments, they would need to have tests to help make sure they don't
get bitrot.

This goes back to what I was talking about with UX/Product/UR doing the
protoyping.  Maybe we should include Devs in the cycle.  We do need to
prototype more and quickly fail the things that aren't successful in our
product.  I think the other thing to keep in mind is... UX people
specialize in the User experience, look and feel.  We should include them
in regards to designs and such to help make the user experience more
successful.  You can have all sorts of cool features in the product, at the
same time if no one uses it because the UX isn't there... can you claim it
to be successful?

All in all we need more engineers and UX people or lower what features are
to be released or change the schedule to something more doable.
Approximate a month ago I looked at some of the numers and we approximately
have a 2 to 1 ratio of dev to managers, 6 to 1 ratio of dev to qa, 7 to 1
ratio or more for dev to ux.

Which then comes to the talk about contributors.  In regards to being open
source and contributors, I think this discussion has been going on from the
start of the project and still hasn't reached a resolution.

Summary : Because of the IP portions in the gonk layer (we don't have
distribution license for those parts), devices, and unsupported nondevice
builds, it has prevented us from getting a lot of the contributor support
we need.

Highlights:
A) We have had 2 dogfood programs.  The second one has been more successful
in getting contributors from internal.  Thanks Jean and Doug esp for
driving this!
B) We narrowed down to a reference device (flame); which helped narrow down
the complexity of devices and getting some contributors, at the same time
we are currently blocked on flame contributor support due to system
partition size issue and the OTA getting too large.  We need to move to
FOTA w/ non IP bits.  Asa plans to help kickstart contributions once we get
FOTA going.
C) Emulator/Simulator (Web IDE)/ Desktop B2G/Mulet:  I would say that most
of these tends to be a bit more on the back end or side items in terms of
major issues or snags.  We really need support focus for these if we want
more contributors.   This is not to discount hard efforts from people that
worked on these... Quite the opposite!  Thank you mulet and web ide team
especially!
D) others : B2GDroid, blobfree tool, flashing tools, etc. These were made
to help lower the bar and/or work around the IP issue.  The problem is the
gonk and lower layers won't be updated so contributors end up suffering
until a distribution by a vendor is made that updates their gonk layer (or
lower) appropriately.

We've tried to work around the main issue of IP that's prevented us from
being completely open.  It's created extra steps and complexity that raises
the bar of the entry point for contributors.  How do we clean up what we
have and lower the bar?

Even more so, how do we get contributors excited to work on B2G?

One part is that we don't have a polished looking OS.  (Which goes back to
Jim's point)

The other thing is that I think is that we have no good ecosystem to draw
people that's evident.  We can say that the world wide web is our
ecosystem; at the same time, we need to clearly make that visible and
message that out.  Ben's work in regards to pinning the web may help show
this better.


On Thu, Sep 10, 2015 at 11:57 PM, Gabriele Svelto <gsvelto@mozilla.com>
wrote:

> On 11/09/2015 02:45, Dietrich Ayala wrote:
> > I'm asking about ways to accelerate feature development in ways that
> > allow more people to participate and more non-release experimentation to
> > occur in the project... and doing it in a way that minimizes the impact
> > on our product release cycle.
>
> Amen to that. Feature flags need not cover fragile, untested bits of
> code that will eventually rot. If we're landing a feature behind a flag
> we can ask for unit-tests, and even integration-tests to be in place
> from day one so it gets a good measure of protection from changes
> elsewhere in the code. This would be *great* for contributors; I've seen
> multiple potential contributions being turned down because either we
> couldn't get UX in place or we couldn't get it on the product roadmap.
> That basically limits contribution to things that are already planned
> for and with UX attached to them. Not an interesting proposition for
> somebody who wants to start contributing because he has a valuable
> feature idea, a specific requirement or just an itch to scratch.
>
>  Gabriele
>
>
>

--001a1142e19efef1da051f7b94d3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div>I agree with Jim Porter=
..=C2=A0 I think we should clean up a lot of the things that we currently ha=
ve; there are so many back log bugs in the system and not all of them are p=
olish.<br><br></div>I agree with Gabriele in that untested code will bitrot=
..=C2=A0 If there&#39;s addons for experiments, they would need to have test=
s to help make sure they don&#39;t get bitrot.=C2=A0 <br><br>This goes back=
 to what I was talking about with UX/Product/UR doing the protoyping.=C2=A0=
 Maybe we should include Devs in the cycle.=C2=A0 We do need to prototype m=
ore and quickly fail the things that aren&#39;t successful in our product.=
=C2=A0 I think the other thing to keep in mind is... UX people specialize i=
n the User experience, look and feel.=C2=A0 We should include them in regar=
ds to designs and such to help make the user experience more successful.=C2=
=A0 You can have all sorts of cool features in the product, at the same tim=
e if no one uses it because the UX isn&#39;t there... can you claim it to b=
e successful?<br><br>All in all we need more engineers and UX people or low=
er what features are to be released or change the schedule to something mor=
e doable.=C2=A0 Approximate a month ago I looked at some of the numers and =
we approximately have a 2 to 1 ratio of dev to managers, 6 to 1 ratio of de=
v to qa, 7 to 1 ratio or more for dev to ux.<br></div><div><br></div>Which =
then comes to the talk about contributors.=C2=A0 In regards to being open s=
ource and contributors, I think this discussion has been going on from the =
start of the project and still hasn&#39;t reached a resolution.<br><br></di=
v>Summary : Because of the IP portions in the gonk layer (we don&#39;t have=
 distribution license for those parts), devices, and unsupported nondevice =
builds, it has prevented us from getting a lot of the contributor support w=
e need.<br><br>Highlights:<br>A) We have had 2 dogfood programs.=C2=A0 The =
second one has been more successful in getting contributors from internal.=
=C2=A0 Thanks Jean and Doug esp for driving this!<br></div>B) We narrowed d=
own to a reference device (flame); which helped narrow down the complexity =
of devices and getting some contributors, at the same time we are currently=
 blocked on flame contributor support due to system partition size issue an=
d the OTA getting too large.=C2=A0 We need to move to FOTA w/ non IP bits.=
=C2=A0 Asa plans to help kickstart contributions once we get FOTA going.<br=
></div>C) Emulator/Simulator (Web IDE)/ Desktop B2G/Mulet:=C2=A0 I would sa=
y that most of these tends to be a bit more on the back end or side items i=
n terms of major issues or snags.=C2=A0 We really need support focus for th=
ese if we want more contributors.=C2=A0=C2=A0 This is not to discount hard =
efforts from people that worked on these... Quite the opposite!=C2=A0 Thank=
 you mulet and web ide team especially!<br></div></div><div><div><div><div>=
<div><div><div>D) others : B2GDroid, blobfree tool, flashing tools, etc. Th=
ese were made to help lower the bar and/or work around the IP issue.=C2=A0 =
The problem is the gonk and lower layers won&#39;t be updated so contributo=
rs end up suffering until a distribution by a vendor is made that updates t=
heir gonk layer (or lower) appropriately.<br></div><div><br>We&#39;ve tried=
 to work around the main issue of IP that&#39;s prevented us from being com=
pletely open.=C2=A0 It&#39;s created extra steps and complexity that raises=
 the bar of the entry point for contributors.=C2=A0 How do we clean up what=
 we have and lower the bar?<br><br></div><div>Even more so, how do we get c=
ontributors excited to work on B2G? <br><br></div><div>One part is that we =
don&#39;t have a polished looking OS.=C2=A0 (Which goes back to Jim&#39;s p=
oint)<br><br></div><div>The other thing is that I think is that we have no =
good ecosystem to draw people that&#39;s evident.=C2=A0 We can say that the=
 world wide web is our ecosystem; at the same time, we need to clearly make=
 that visible and message that out.=C2=A0 Ben&#39;s work in regards to pinn=
ing the web may help show this better.<br></div><div><br></div></div></div>=
</div></div></div></div></div><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">On Thu, Sep 10, 2015 at 11:57 PM, Gabriele Svelto <span dir=3D=
"ltr">&lt;<a href=3D"mailto:gsvelto@mozilla.com" target=3D"_blank">gsvelto@=
mozilla.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D"">On 11/09/2015 02:45, Dietrich Ayala wrote:<br>
&gt; I&#39;m asking about ways to accelerate feature development in ways th=
at<br>
&gt; allow more people to participate and more non-release experimentation =
to<br>
&gt; occur in the project... and doing it in a way that minimizes the impac=
t<br>
&gt; on our product release cycle.<br>
<br>
</span>Amen to that. Feature flags need not cover fragile, untested bits of=
<br>
code that will eventually rot. If we&#39;re landing a feature behind a flag=
<br>
we can ask for unit-tests, and even integration-tests to be in place<br>
from day one so it gets a good measure of protection from changes<br>
elsewhere in the code. This would be *great* for contributors; I&#39;ve see=
n<br>
multiple potential contributions being turned down because either we<br>
couldn&#39;t get UX in place or we couldn&#39;t get it on the product roadm=
ap.<br>
That basically limits contribution to things that are already planned<br>
for and with UX attached to them. Not an interesting proposition for<br>
somebody who wants to start contributing because he has a valuable<br>
feature idea, a specific requirement or just an itch to scratch.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
=C2=A0Gabriele<br>
<br>
<br>
</font></span></blockquote></div><br></div>

--001a1142e19efef1da051f7b94d3--

On 09/11/2015 01:57 AM, Gabriele Svelto wrote:
> On 11/09/2015 02:45, Dietrich Ayala wrote:
>> I'm asking about ways to accelerate feature development in ways that
>> allow more people to participate and more non-release experimentation to
>> occur in the project... and doing it in a way that minimizes the impact
>> on our product release cycle.
> 
> Amen to that. Feature flags need not cover fragile, untested bits of
> code that will eventually rot. If we're landing a feature behind a flag
> we can ask for unit-tests, and even integration-tests to be in place
> from day one so it gets a good measure of protection from changes
> elsewhere in the code.

I don't think that's actually achievable with feature flags. Unless
we're fully-dedicated to removing feature flags as quickly as we can,
we'll end up with a combinatoric explosion in our test matrix. Given the
staffing issues mentioned earlier in this thread, I don't trust our
ability to keep the number of feature flags to a manageable level. We
also don't have the computational resources to test every combination of
feature flags, so we'd be relying on our imperfect understanding of
whether each feature flag is truly independent.

> This would be *great* for contributors; I've seen
> multiple potential contributions being turned down because either we
> couldn't get UX in place or we couldn't get it on the product roadmap.

If we can't get something on the product roadmap, doesn't that mean that
we don't actually want it anytime soon? I don't think we should take
every contribution someone offers us if they don't meet our goals.

To be fair, we really need a better long-term idea of what stuff we want
for each app (not necessarily for the next release). One of my main
goals this month for the Music app is to triage all our bugs so that a
prospective contributor can just look at our bug list to find something
to work on that has a reasonable chance of landing.

> That basically limits contribution to things that are already planned
> for and with UX attached to them. Not an interesting proposition for
> somebody who wants to start contributing because he has a valuable
> feature idea, a specific requirement or just an itch to scratch.

I don't think we can compromise on quality just to get more people to
contribute to the codebase. If patches aren't getting feedback in a
timely manner, the solution isn't to stop asking for feedback.
Volunteers more than anyone else need guidance from dev, UX, *and* QA,
since they're not already immersed in our processes.

Much of this discussion also assumes that the only volunteer
contributors we'll get are developer-types. I don't think that's
necessarily true; I'm sure there are plenty of folks who'd be very
interested in providing UX for new features. However, we'd first need a
list of general features we want in the long-term, and then we'd need
enough full-time UX people that they could afford to spend some time
mentoring new contributors.

- Jim