--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= 's quite likely that the patches no longer apply.<br><br>However, the p= roblem isn't really that these are blocked on UX input. Even if UX give= s input, and designs full specs for the feature, we don't have full eng= ineering support, QA support and we don'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't actually targeted for any releas= e - it'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= 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'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--
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
--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 <<a href=3D"mailto:jporte= r@mozilla.com">jporter@mozilla.com</a>> 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> > Whatever the solution, we need to find a way to enable feature<br> > development with as few restrictions as possible, without risking<br> > overall stability. Got any ideas on how to do that?<br> <br> Hire more UX people so the ones we have aren'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--
![]() |
0 |
![]() |
--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"><<a href=3D"mailto:autonome@g= mail.com" target=3D"_blank">autonome@gmail.com</a>></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 <<a href=3D"mailto:jporter@mozil= la.com" target=3D"_blank">jporter@mozilla.com</a>> 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> > Whatever the solution, we need to find a way to enable feature<br> > development with as few restrictions as possible, without risking<br> > overall stability. Got any ideas on how to do that?<br> <br> Hire more UX people so the ones we have aren'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--
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
--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'm actually suggesting *less* UX, QA and re= lease support. We don't want or need it for experimental features. Righ= t now, there'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'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's not at all what we'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 <<a href=3D"mailto:jporter@mozilla.com">jporter@mozilla= ..com</a>> 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> > Hiring more designers is not a solution. Blocked on design is only a<b= r> > 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'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'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'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 "... 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."<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'= t<br> in-tree. I've done as much in my Thunderbird work, and it's functio= nally<br> very similar to working in a branch. However, I don't think they'd = be<br> much help with the bugs you mentioned, which don'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--
![]() |
0 |
![]() |
--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've described an ideal version of a = typical software development cycle. (Or not ideal nor typical, depending on= where we've all worked before!)<br><br>But we're not in that situa= tion.<br><br>We'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'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 <<a href=3D"mailto:nhirata@mozilla.co= m">nhirata@mozilla.com</a>> 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"><<a href=3D"mailto:autonom= e@gmail.com" target=3D"_blank">autonome@gmail.com</a>></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 <<a href=3D"mailto:jporter@mozilla.com" target=3D"_blank">j= porter@mozilla.com</a>> 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> > Whatever the solution, we need to find a way to enable feature<br> > development with as few restrictions as possible, without risking<br> > overall stability. Got any ideas on how to do that?<br> <br> Hire more UX people so the ones we have aren'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--
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
--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"><<a href=3D"mailto:dietrich@mozilla.com" target=3D"_bla= nk">dietrich@mozilla.com</a>></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's not even on= =20 the wiki yet, but here'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'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= 9;s WiP branch</a> for how we use it for enabling/disabling the "Firef= ox Sync" 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--
![]() |
0 |
![]() |
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--
![]() |
0 |
![]() |
--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's addons for experiments, they would need to have test= s to help make sure they don'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'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'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't reached a resolution.<br><br></di= v>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 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'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've tried= to work around the main issue of IP that's prevented us from being com= pletely open.=C2=A0 It'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't have a polished looking OS.=C2=A0 (Which goes back to Jim'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'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'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"><<a href=3D"mailto:gsvelto@mozilla.com" target=3D"_blank">gsvelto@= mozilla.com</a>></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> > I'm asking about ways to accelerate feature development in ways th= at<br> > allow more people to participate and more non-release experimentation = to<br> > occur in the project... and doing it in a way that minimizes the impac= t<br> > 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'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've see= n<br> multiple potential contributions being turned down because either we<br> couldn't get UX in place or we couldn'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--
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |