Technical Agenda

[rae]

During last Friday’s WG meeting, I wanted to ask about whether we should embark on our technical agenda, or whether we should wait for the Board and ED to be installed.

Of the different directions we thought the HF might want to explore, one seems easiest to execute on:

Windows support. Currently Windows commands a plurality of potential users, yet GHC’s support suffers from instability and poor user experience. The HF will address this by fostering the coordination of fixes for the known Windows-specific issues and the promotion of a proper installer.

A slightly harder one:

Streamline the profiling experience. Building high quality haskell applications requires the ability to have a good understanding of runtime characteristics. While we have a plethora of tools ranging from the slightly antiquated hp2ps, to newer eventlog-based tools like ThreadScope, to live monitoring in the form of EKG, we do not have a unified profiling framework nor the supporting documentation for such. The HF will foster unifying existing tooling and assist with existing or new work on documentation and best practices around profiling Haskell applications, while having an open ear for the needs of industrial applications of Haskell.

(Both of these are cribbed from the technical agenda, which is requested to be posted on the website by https://github.com/haskellfoundation/haskell.foundation/issues/38.)

Should we execute? And, if so, which one? How? The second seems inherently to require some opinions, so I’m hesitant to move forward without e.g. an ED to have opinions. But maybe I’m wrong here.

My sense is that we may want to capture our momentum. And, from a fund-raising standpoint, it certainly looks good if we’ve accomplished some goal right away. Thus, my desire to get moving.

Yet: My thought is that our first line of attack on any technical issue would be to identify people already working in a space and seek to support them. To me, though, it’s unclear how we could support them at this point. We have money raised, but we don’t have any employees. We could, I suppose, pay someone (e.g. a contractor) to do this support work… but that seems rather roundabout and inefficient – especially when we might have an in-house employee in the not-too-distant future who could do the support work.

So I’d love feedback and thoughts from the group here about what our next steps should be. I feel there are strong reasons both to blast forward and to wait.

[adamgundry]

I don’t have a clear view on whether the HF should press ahead with the technical agenda vs wait for an ED/full board. As you say, there are arguments in both directions. But regarding this point:

@rae

Yet: My thought is that our first line of attack on any technical issue would be to identify people already working in a space and seek to support them. To me, though, it’s unclear how we could support them at this point. We have money raised, but we don’t have any employees. We could, I suppose, pay someone (e.g. a contractor) to do this support work… but that seems rather roundabout and inefficient – especially when we might have an in-house employee in the not-too-distant future who could do the support work.

What does “support work” mean in this context? Is the intention that the HF will be directly hiring employees to take on technical activities such as developing tools and writing documentation, especially where there is already work ongoing? I had the impression the HF’s role would be to coordinate at a higher level.

I’d be concerned that employment can be quite “roundabout and inefficient” compared to contracting out specific tasks, especially as those tasks may require various different skill sets (e.g. Windows knowledge vs. low-level GHC RTS work on profiling vs. building user-friendly UIs vs. documentation). Moreover, contracting gives you much more flexibility to engage developers for specific projects rather than on an ongoing basis.

Of course I have a vested interest here, because at Well-Typed we have been offering exactly this sort of contracting for a long time, with a particular focus on GHC/Haskell tooling. In fact Matthew Pickering and David Eichmann at Well-Typed are currently working on improvements to profiling tools in partnership with Hasura. There was a brief mention of this in our last GHC activities report, and we’re planning to post more coherent details of what we’ve been doing soon, but I’m very excited about the possibilities unlocked by the combination of the new info table profiling mode + eventlog2html + ghc-debug. We’d be very happy to scale up this work if more funding is available, or to collaborate with others interested in working in this area.

[rae]

Good points, Adam.

I think I’m worried about the chance that the needs will be too small. Maybe a project needs an initial investment of 10-20 hours to set up some CI infrastructure, along with 2 hrs/week for maintenance. But that strikes me as a small contract – hence inefficient. If the HF were supporting multiple projects that all had similar-sized needs, this works out great: we contract with someone and then aggregate the needs. Indeed, this feels like a real win for the HF, and everyone else. Yet, if we don’t have further needs yet, then it feels inefficient to me. This feeling could be entirely wrong, though – this isn’t my area of expertise or experience.

I may also have been wrong when I said that I expect to have an in-house person to do support work. This support work was meant to be lightweight… but I’m struggling to define what would be lightweight enough to include. And my comment was just a supposition – I have not been involved in any discussions of this sort of in-house work.

[simonpj]

I don’t think we want to make any medium/long term commitments until we have an ED and Board in place. So I think that rules out hiring staff, for now. For now, contracting I think.

But I think it’s open to the working group to invite the Interim Board to fund any short-term, limited-duration pieces of work. The criteria I’d suggest might be

• Modest in scale (i.e. a limited commitment)
• Important to users
• Not getting done at the moment (the role of the HF is to fill gaps, not to duplicate)

[alexander_bernauer]

@rae

During last Friday’s WG meeting, I wanted to ask about whether we should embark on our technical agenda, or whether we should wait for the Board and ED to be installed.

Thank you, Richard, for starting this conversation.

I agree that Windows support and a streamlined profiling experience are important points. What I believe would be beneficial to add is a higher level map and strategy that explains how these points, among others, are expected to foster adoption. This would also allow us to populate our backlog comprehensively and to prioritise its items consequentially.

Being new to the working group, I was wondering, if there is already a strategy in place, and if not, what would be the right approach to go about establishing one. Is the technical track the right place for this, for example?

In my mind, as I have mentioned during our last meeting, one key strategic objective should be to lower the personal risk that corporate decision makers are taking when they select Haskell. I would be keen to engage in a discussion with you or anyone else and share my thoughts about and experience with this.

Kind regards,
Alex

[rae]

Yes – there is a draft, early-days technical agenda. This was intended to be put on the website, but got left out in the final scramble. There is a ticket to correct this oversight.

I’m eager to continue to develop this agenda (I was the chair of the “task force” that wrote it), but I worry about wasted effort in continuing to build this before the ED and Board are installed. Once that happens, I expect to launch back into this work, and quickly. I’d love your input (or anyone else’s).