HLS prioritization and product development

[hasufell]

Since we have a contract with WT and a number of contributors, we should start being a little more product oriented and create a priority list.

E.g. my opinion on the top 3 features missing are:

1. Can not go to definition of non local libraries (i.e. dependencies) #708
2. Type information for arbitrary portions of code #709
3. a plugin for adding new modules to a cabal file (briefly discussed with @fendor ... seems possible and would make e.g. hpack obsolete, as well as many odd requests to cabal)

For non-functional priorities, I'd say:

1. performance of HLS (including memory footprint)
2. better/swifter releases (lock-step with GHC)
3. cross-compiler support (new ghcjs... was this discussed? Does it even work?)

So far, I propose to discuss priorities and write them down in the readme or contribution document. Then figure out what the status of each of those is, what blocks them and if we have enough volunteers or funds to execute some of it.

---

@wz1000 @michaelpj @fendor @pepeiborra @david-christiansen @Kleidukos

[michaelpj]

I think let's discuss this in our next meeting, can you add it to the agenda?

Rather than the readme or whatever, I think we could either make use of the wiki or a github project to track priority issues.

Realistically, apart from WT I think our contribution bandwidth is still somewhat limited, so I think this may mostly prove relevant for them.

[hasufell]

I think our contribution bandwidth is still somewhat limited

Surely, but excited contributors would probably be most interested in tickets that get them the most fame... so there's additional incentive to tackle these tickets.

[fendor]

Re 3., @VeryMilkyJoe is working on it, they have a somewhat working prototype. The first iteration will be up, soonish.

EDIT:

I think a public priority list is a good idea.

[wz1000]

These are certainly some possible directions of work, some like @fendor points out are already underway.

For 1, we already have a summer student with a WIP PR here: #3704

I would suggest prioritising more mundane directions of work, such as making the testsuite reliable, GHC compatibility, release management when no other volunteers are available, and performance/memory usage work.

[hasufell]

I would suggest prioritising more mundane directions of work

Well, the idea is not so much about what we can reasonably or easily achieve... but what needs to be done for HLS to be a better LSP tool, product wise. And then we figure out IF we can do something about it. And if not, we may need more funding.

[Kleidukos]

I fully support this initiative of making the priority list public, it certainly helps build trust in the development process.

[michaelpj]

Well, the idea is not so much about what we can reasonably or easily achieve... but what needs to be done for HLS to be a better LSP tool, product wise.

I think that I agree with Fendor largely because it seems to me that we are in a maintainability trap. Working on HLS is too difficult, and this leads directly to us getting less stuff that people want. The trouble comes from multiple directions, but I think that to a significant degree getting the project more maintainable means we get more features in the end!

[hasufell]

The trouble comes from multiple directions, but I think that to a significant degree getting the project more maintainable means we get more features in the end!

Sure, let's not get side-tracked about daily operations of open source projects.

I think this is orthogonal and not in conflict with what I'm saying. I'm really talking about roadmaps and things that end-users are interested in. I don't think end-users care about our CI at all, although it's a very important part of HLS operations and the contribution experience.