Suggestion: have public milestones

[SergioMorchon]

As a developer using Flow, it would be nice to know the milestones of this project: how issues are organized & planned and what's going on with the project in general, instead of only what's already done.
Under my perspective, it would make this project a bit more open/visible to newcomers or devs considering using it.

[LaurensBosscher]

Compared to Typescript there's not a whole lot of buzz around Flow. Both the Twitter and Blog have not been updated for several months, it's not a huge issue but visible activity around a project is usually a positive indicator. Public milestones or a roadmap would be useful!

[oriSomething]

I can say one of the reason where I work we're migrating to TypeScript is a lack of transparency.
Knowing what are the plans for the future instead of guessing it from version release notes, is much more assuring

[mrkev]

DISCLAIMER: I'm not in the flow team. I work at Facebook, have met and know a couple of people in flow, and like to help out when I catch a few spare cycles, but all of this is very much my take on things from what little I know.

IMO a large part of the problem is that the roadmap for the rest of 2018 is very inward-looking. Some rough context:

Facebook is at an interesting part of its lifetime in that the codebase is growing exponentially in size but of course development machines can't just grow exponentially in memory and CPU at the same rate. When the team got started around 4 years back, there was about 10,000 files to typecheck. This time last year, it was over 100,000, and at the moment it's probably 2x or 3x that.

A lot of the problems the community has are also problems that are very annoying to developers internally-- but on top of that there's this very unique-to-Facebook uber-headache that is performance at the scale of our codebase. The level of interconnectedness and the crazy structures you find in a dependency graph that big, the amount of code data to churn through the parser, the speed at which it all changes when you have thousands of developers constantly pushing code throughout the day-- and it all has to run live on every developer's machine and fast!

I understand the frustration, but I also understand how much time and effort goes into keeping the community looped-in, looking through issues, answering questions, etc-- it's like another full-time day-job that the flow team unfortunately doesn't have at the moment because the time crunch to optimize flow is very real. On top of the lack of time, a lot of the work is exploratory and experimental, nuanced details about parallelism and memory management, linux cgroups, etc. I can see releasing a roadmap being in some ways an invitation to start a conversation about future plans in a context where there's little resources to invest in that conversation (this comment alone for example is taking like 20+ minutes to write, and I imagine will bring about more discussion. I wonder how many people-hours a well-fleshed discussion in, say, the React Fire announcement thread takes).

No hard feelings about switching to TypeScript. I'll keep checking in and suggesting more community involvement because I know the team cares, but unfortunately things are busy. Lmk if/how I can help though.

[oriSomething]

@mrkev Just saying lack of transparency wasn't the main reason we're migrating to TypeScript. But lack of transparency means I have no idea if issues we have will be solved or not

[lll000111]

@mrkev

DISCLAIMER: I'm not in the flow team. I work at Facebook,

Thanks for your contributions! However, this leads me to the question if there is anyone from the Flow team on Github at all? On TS Github there even is the project lead, and he actually responds to regular users posting issues (I know because I received an answer and even a patch for TS from/through him, and I posted less than a handful of issues there). Compare to Flow, where there doesn't seem to be anyone around from the core team, and if there is someone it's not apparent.

It's not a complaint, as a long-time user I have long noticed and resigned myself to the fact that any usefulness of the project to anyone outside of Facebook is merely coincidental, the project is inward-looking. Okay. Not sure what choice (of a type system) I would make today though. I think yet another discussion about it is useless (this is hardly the first such issue). Maybe there should be a clear explanation and each time somebody complains you can just point to it and close the issue, because I don't thing anything will ever come from it.

The project's aim is not to create a "product" so there's not much left to discuss, right? It is in the spirit of open source of "Use at your own risk (but we really only wrote it for ourselves)". The problem may be that it appears to be a product, competing with TS on an equal level, and you only find out that it isn't so after spending some time here in the issues. So, tot probably could use better up-front expectation management.

[jcready]

At some point someone on the Flow team did make these, but they were both closed last month: https://github.com/facebook/flow/projects?query=is%3Aclosed

[mrkev]

They weren't really updated and tags serve much of the same purpose.

[SergioMorchon]

I'm really happy with the changes done regarding the public activity of this project :)

https://medium.com/flow-type/what-the-flow-team-has-been-up-to-54239c62004f

Thank you for listening us!

[vjpr]

What would be great is if they added the tasks to Github so we could see what they are prioritizing. Or even one issue to show the milestones as checklists.

There are so many issues that prevent Flow actually working at all on projects, and that have been open for years.

I was forced to move to TypeScript because Flow simply didn't work because of simple missing features:

• doesn't support module aliases (there is a PR to fix) - [FEATURE] Add module_alias resolution capabilities #7185
• not able to ignore all node_modules without getting cannot find module errors, or being able to include node_modules with typings (ignore config precedence) - Don't typecheck or load files under node_modules/ unless they're imported by flow-typed files #869
• search upwards for flow-typed dirs - Support flow-typed directories in yarn workspaces #5183

There are many people who also left because of these issues that were never resolved. Even Facebook's own projects are leaving.

From medium post:

The projects that have decided to switch to TypeScript have external contributors whose lives will be much easier with this switch, and we respect these decisions.

Why would there "lives will be much easier with this switch"? Because they can actually use the product!!!

Can't you take a sprint to just fix the things preventing people using the product at all?

[nmote]

#869 has a lot of history and I didn't read through the whole discussion, but that actually is how Flow works now. It doesn't typecheck node_modules unless they are referenced from code which is flow-typed.

We're working our way through the backlog of PRs. We have 30% fewer open PRs today than we did a couple weeks ago. I definitely understand your frustration but we're doing our best to get through them. With that said, I just pinged @jbrown215 to ask him to prioritize #7185 (I think he is out right now but he should be back on Monday or Tuesday).

We're prioritizing pull requests over issues at the moment, but we also intend to work on our backlog of issues. In the meantime, I'll at least read through #5183.

Let's continue this discussion over on #7426. I think it will be good to centralize the discussion around high-priority pain points there.