Fix bugs or add features?

[KevinRansom]

Let's be clear
As of 31st December the project to add F# 4.0 language improvements and FSharp.Core.dll enhancements was declared complete.

• https://github.com/Microsoft/visualfsharp/wiki/F%23-4.0-Status

We are trying to ensure that F# 4.0 ships with at least the same high quality as previous releases of F#. The issues page currently has 50 open bugs : https://github.com/Microsoft/visualfsharp/labels/bug

I understand the issue is that fixing bugs in the F# compiler and FSI is very hard. At least I find it very tough and usually slow going. Figuring out the right fix is equally tough and there is always the fear that now I have broken something else.

I have noticed that we have received a number of PR's for unsolicited features recently. I think these are great PRs and valuable additions, but they also distract us from knocking down the bug count.

We have achieved our F# Language and FSharpCore feature goals for this release, we are not yet close to achieving our quality goals.

How can you help?

• Find Bugs! anything that doesn't work right is a bug!
• Help us investigate the issues we have, which are the most important to fix now?
• Fix bugs
  • Pick a bug
  • check to see if it's assigned to anyone
  • note that you are interested in fixing it
  • investigate and propose a fix

Kudos to Stefan, has bit the bullet and supplied some fixes and investigations this year.
I know that you want an upforgrabs field, I can add Up - For Grabs to every bug if that would be easier. But right now if it's a bug and unassigned, that is exactly the same as up for grabs.

It should be noted that low risk enhancements to the UI layers are still acceptable, because often the lack of the feature is regarded as "a bug", and we still have progress to be made there.

What do you think about focusing for the short term on raising quality, is it a good or bad approach?

Kevin

[alfonsogarciacaro]

I agree with you, the core team should focus on delivering a high quality product by fixing issues before implementing new features. But it's in the nature of F#ers to always try pushing the language forward.
Hopefully now there'll be more people willing to give a hand after the move to GitHub. I hope I can do it myself soon when I have the time and the courage to dive into the compiler, but I need to focus on FunScript for the moment.
I second the kudos to Stefan too!

[forki]

Thanks for mentioning me here.

I think it's super important to fix as many bugs as possible even if they look like the strangest edge cases. This will improve the overall quality by adding more and more tests. But as always the hardest part is to reproduce a bug. @KevinRansom please provide a small tutorial/video of how you debug an issue in the compiler and in the fsi.

[ashtonkj]

My 2c. The only features that I feel should still be being added are those that have to do with the Visual Studio integration / IDE features that we are used to from other languages (I know the Visual F# Power Tools team has done a lot of excellent work on these, but I am of the view that some should be moved into the core to allow the VFPT team to experiment with new features). Essentially taking the same approach as VS Web Essentials, where once a feature is stable in VFPT it gets migrated to the core product, thus improving the usability of the tooling for any new user that doesn't know about VFPT.

[dungpa]

What do you think about focusing for the short term on raising quality, is it a good or bad approach?

Yes, it's definitely a good approach.

It's fine to say that all issues are Up For Grabs. However, another meaning of Up For Grabs issues is to attract new (potential) contributors. Ideally an Up For Grabs issue should be small (required a few hours of investigation/bug fixing) and doesn't require ultimate knowledge of the code base. I think it's much better if you explicitly put Up For Grabs labels on such issues. To be honest, I went through all the bugs on the repo many times but didn't find any issue that is that easy to fix. Hope that I'm wrong here.

Another thing would be of great help is that you add a few tips on concrete issues how to start an investigation on those. It's tough to do bug fixing because we (contributors) don't know where to start. I know it's hard to add more information on those issues you aren't going to fix (soon), but it's really useful to grow contributions on the project, especially on the bug fixing side.

[enricosada]

Sry as usual is too long

I understand fix existing bugs is important.
Some bug are not easy, a fix require more time than a feature of same size (without hints or a clear repro).

Some bugs are really old, with workarounds, maybe we can try to fix these and trying to change the codebase in a direction who can help fix issue faster in the long/medium run (the FAKE build pr #15 is an example). At work i see lot of old codebase 😭 ...

I really like to help, f# is really nice and the people too.

I think new features or improvements are important

A new feature is something i want to add because is annoying in the current status or i miss when i use the program.

I think we need to both fix some bugs, but is also very important to improve the codebase for future work, there is a lot of technical debt (see the vs project system) who can help move faster if fixed

Easier to start contribute with little features than bug

Add a new feature is easier when i want to start contribute or explore the project (for me at least). the scope is smaller and i can use already existing code as a starting point.

A little new feature help me understand better the project (people/architecture/test/style/docs). Or part of the project because the compiler is a lot different development than the vs extension (i need to use time to learn).

Is not a zero sum game

Some people is not interested in fix bugs or like to work on some part of the repo.

In this repo:

• compiler
• fsi
• vs extension
• shared code with open fsharp (library for example)
• compatibility (the tests suite)
• code used for other really interesting project (see fsharpbinding, type providers)
• documentation

there a tons of stuff (web/console/etc), tons of motivated people for different reason

What i want to do

After i learn the basic stuff i'd like to try something more fun, and help the others there.

For now, no compiler work for me, or fsi or f# 4.0 library stuff

i'd like to focus on:

• library bugfix
• vs extension bugfix
• documentation
• perf (i'd like to learn more about that), see @jack-pappas work

The big tasks i am trying to do now:

1. port the whole test suite (fsharp+fsharpqa) to openfsharp

• need to replace the perl/.bat runner (or add alongside the current) with nunit
• easier if the two repo are not too different (=> align whitespace, codebase where possibile)

1. fix the current vs project system a bit
   • align the old c# base system with the really good codebase of pytools (our is an older version of same base project system), i mean whitespace
   • upgrade shared codebase with pytools one feature/bug at time (add files/folder/rename/lot of stuff)

Future stuff i can help with, if needed, and i'd really like to:

• improve ci
  • i do that at my work and know how to do a good job with jenkins, build matrix, test suite, slaves
  • alongside appveyor and travis, not a replacemenet (these are nice for personal fork), but a more comprensive suite (os matrix, .net profiles matrix)
• improve testing
  • add fscheck
  • fuzzy
  • performance

[dsyme]

closing old discussion