new features, bitrot & killswitches

[Dietrich Ayala]

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?

[Jim Porter]

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

[Dietrich Ayala]

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 <jpo...@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-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-gaia

[Etienne Segonzac]

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

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

Yes!

Giving us back our ability to experiment and iterate is a killer use case for addons!

In the sytem app in particular, they can go a _long_ way (because of the modular architecture).

We'll need to use the settings in the developer menu some times, but it's not as clean when it comes to "not including the code", unless we do mozSettings + build time settings which adds a bunch of complexity.

[Fabrice Desré]

On 09/10/2015 02:41 PM, Etienne Segonzac wrote:
>
> On Thu, Sep 10, 2015 at 11:01 PM, Dietrich Ayala <diet...@mozilla.com
> <mailto:diet...@mozilla.com>> wrote:
>
> I don't know that killswitches are the right answer. Maybe add-ons
> are, at least for the front-end parts?
>
> Yes!
>
> Giving us back our ability to experiment and iterate is a killer use
> case for addons!
> In the sytem app in particular, they can go a _long_ way (because of the
> modular architecture).

Are you confident that the add-ons will not bitrot often as we make
changes to the system app? Or should we expose an explicit API for
add-ons to hookup into gaia features? Eg, instead of directly touching
the DOM to add a new option to the quick settings, expose a js api?

Fabrice
--
Fabrice Desré
b2g team
Mozilla Corporation

[Naoki Hirata]

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 <auto...@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 <jpo...@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-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-gaia

[Jim Porter]

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

[Dietrich Ayala]

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 <jpo...@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 :)

[Dietrich Ayala]

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 <nhi...@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 <auto...@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 <jpo...@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-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-gaia

[Eric Shepherd]

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?

I think anything that can be done in this area is a great idea; I encourage you to be sure to keep the docs team apprised so we can be sure that best practices and how-to documents are created and positioned properly for discoverability, if/when this happens.

--

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability

[Jim Porter]

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

[Jim Porter]

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

[Etienne Segonzac]

On Fri, Sep 11, 2015 at 12:42 AM, Fabrice Desré <fab...@mozilla.com> wrote:

Are you confident that the add-ons will not bitrot often as we make
changes to the system app? Or should we expose an explicit API for
add-ons to hookup into gaia features? Eg, instead of directly touching
the DOM to add a new option to the quick settings, expose a js api?

The system app's index.html contains only the really basic DOM + legacy stuffs.

It does move from time to time but it's manageable (hell, the addon API itself moves from time to time ;)).

All "up to date" modules render their own DOM *and* they have .start() and .stop() method.

Each module also publishes events when it's loaded/rendered/... so the exact moment where the addon is loaded is not that big of an issue.

Again, not a silver bullet, but we can do a lot :)

[Michiel de Jong]

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

On Thu, Sep 10, 2015 at 11:01 PM, Dietrich Ayala <diet...@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

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 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.

[Gabriele Svelto]

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

[Andrew Sutherland]

On Thu, Sep 10, 2015, at 06:42 PM, Fabrice Desré wrote:
> Or should we expose an explicit API for
> add-ons to hookup into gaia features? Eg, instead of directly touching
> the DOM to add a new option to the quick settings, expose a js api?

Yes. The ideal would be that integrating an extension feature into core
would be just copying the files into the tree and adding an explicit
require() dependency somewhere. (And ignoring some
boilerplate/metadata.)

If add-ons are forced to monkeypatch themselves into existence, it's bad
news for everyone. (Sometimes it may be the only option for complex
things, but if it's always the only option, that's sad.)

Speaking as an app developer, probably the most useful thing I (and
others) can do is to provide simple example add-ons that can serve as
hacking starting points for actually useful functionality. I'll spin
off another thread on that for the email app to try and gather some
ideas as to where would be good for me to start.

Andrew

[Fabrice Desré]

What's the rationale for adding this kind of preprocessing? Are we
running tests both with and without the flag set? What is the value of a
build without FXOS_SYNC?

In gecko we try to reduce our use of #ifdefs at least in JS code for
features, and this is the kind of change that should have been discussed
on mailing lists before landing (if it was, my apologies).

Fabrice

On 09/10/2015 11:51 PM, Michiel de Jong wrote:
> (retrying list posting, apologies if this reaches the list twice)
>
> On Thu, Sep 10, 2015 at 11:01 PM, Dietrich Ayala <diet...@mozilla.com
> <mailto:diet...@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.
>
>
>

> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
>

[Fernando Jiménez Moreno]

Having preprocessing in Gaia allows us to add/remove features if:

- We don't meet a specific deadline.

- We identify a last minute security or functionality issue before shipping the product.

- We (or a partner) wants to ship a product without a specific feature. For example, the Red-Square (feature phone) or the TV projects may not want to add Firefox Sync to their products. We need to provide them with a way to remove a feature from their builds without needing to remove any code from the tree.

We already suffered that in the past. For example, we had to remove Firefox Accounts from the TV and now we need to reintroduce it in the tree [1]. Also e.me or the Facebook integration in Contacts are features that would have benefit from this.

Apologies for not sending this to the mailing list before landing. We involved the build system owners though.

Cheers,

/ Fernando

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1202360

[Naoki Hirata]

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.

[Julien Wajsberg]

Le 10/09/2015 23:01, Dietrich Ayala a écrit :
> 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.
>

In my own experience developing for the SMS application, I was never
blocked once from UX or Visual Design input. They always provided specs,
even for lower priority tasks. Sometimes I needed to ping them directly
by mail but I think it's OK, I'm not always 100% responsive either.

BTW, when you write "months", you likely meant "weeks" in the 2 bugs
you're mentioning.

So my solution is: we need UX owners for all parts of Gaia.

> 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.

IMO that's the role of UX to come up with consistent states, from a
small part of a feature to the full feature, with the help of the
developers of course.

>
> 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.

In the SMS team we used a killswitch for 1 case only: the "support email
recipient" feature. It was necessary because it was not possible to keep
a consistent state while landing separate patches. Both states were unit
tested, but not integration tested. The integration tests were covering
only the default state.

Otherwise we always managed to keep a consistent state, patch by patch.
It's slower but as other people said it's more testable.

--
Julien

[Jim Porter]

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