motivation for new CTO
89 views
Skip to first unread message
Richard Eisenberg
Dec 16, 2021, 8:35:49 AM12/16/21
to Haskell Foundation Board
Hi all,
Gershom Bazerman (a stalwart in the New York City Haskell scene and co-leader of the Haskell infrastructure team) reached out to me recently to voice a concern over the transition away from Emily as CTO. I encouraged him to write up his viewpoint as we consider what the best next steps are around our staffing. I post his words, below:
------------------------------
*Motivation for and Responsibilities of a Haskell Foundation CTO*
In our discussion on Thursday (Dec 2), Richard posed to me the
question of if the HF was better suited if it just hired a series of
contractors to work on tickets, or if it devoted resources as well to
a high level technical (i.e. CTO) hire. I want to motivate the latter,
based on my understanding of what the HF was intended to do (as
described and motivated to me) from its conception, as well as the
history of some prior, defunct attempts (notably the Industrial
Haskell Group), and finally the experience of the last year or so of
HF existence.
*HF Must Work with Modest Resources*
The financial resources available to the HF are relatively modest. We
understand that outside of core work, the bulk of development done on
the Haskell ecosystem (including core work on GHC, build tools, ides,
etc) is necessarily going to have to continue to come from volunteer
contributors or in-kind donations of development time from companies
-- further, I would not wish to change this, as it would too much
centralize the ongoing health of the Haskell world on one source of
support and funding. Hiring contractors to handle individual tickets
is a route at most to incremental improvements, and relatively small
ones at that -- in particular they will just be individual
contributors in a sea of other contributors. Further, it poses the
problem of picking which tickets to work on -- too large and there's a
high risk factor (and significant expertise required), too small and
there's increasingly less point. Further, proposing and getting
consensus on these tickets, and motivating them sufficiently as "wins"
etc provides a significant time overhead, and also expectations of
detailed reporting, which creates more overhead. Companies
increasingly start seeing themselves as donating to get specific work
done, and then weighing that against their own ability to just hire
people to do the work they want themselves will invariably find the
latter more cost-effective. This is the "IHG trap," why it couldn't
scale up, and why it eventually became defunct.
*Technical Leadership Provides a Force Multiplier*
The value proposition of the HF was precisely that it would not be
"IHG 2.0" but instead focus on being a force multiplier. In the
current state of the Haskell ecosystem there are a lot of enthusiastic
and willing contributors. What many core projects lack is
coordination, direction, and guidance (which are necessary aspects for
e.g. communication and onboarding as well). Many libraries are in
"maintenance update only" mode or semi-abandoned. There are trackers
with far too many languishing PRs, feature requests without a full
spec, half-finished discussions left fallow, etc. The problem is not
the will to contribute -- it is that there is not enough focus on
fostering and enabling contributions, because of lack of direction.
People don't lack ideas or will, they get dispirited because there is
nobody to say "yes, if you proceed, I will help you find answers to
problems you encounter, and work to make sure this is resolved, and
ideally merged," or nobody to say "out of all these issues, here are
five that you might be suited for, and also which definitely would be
welcomed if they were accomplished." More individual contributors,
paid or otherwise, doesn't help resolve this directionlessness and
logjam. There are people who could, and have, volunteered to help lead
some of this. But 1) they often don't feel empowered to step up as
leads if they haven't already been longtime contributors and 2) the
time commitment involved in ongoing attention is much greater than
occasional focused pull requests, the level of responsibility for
merging a PR and making a release is much different than making a PR,
etc.
*Technical Leadership Requires Attention and Depth*
What is needed both at the project level, and ecosystem level, is
technical leadership that can take responsibility for identifying
these logjams, sorting through the wide range of tickets and
highlighting the most important ones with broadest impact, and
highlighting them to source contributors (if you just say "Haddock
needs help" you won't get many takers -- if you motivate "here are
three tickets that would really be welcome and neat!" you stand much
better odds), anticipating which arenas are most languishing and in
need of attention, providing or sourcing guidance to help contributors
who get stuck, and empowering individual contributors to themselves
step up as maintainers (a leap people don't take unless pushed). A key
element here in motivating contributors is also responsiveness – being
able to answer tickets or PRs in a timely fashion so nobody feels
their work is languishing (which is tremendously demotivating for any
future work or interaction).
This requires a fair amount of rolling up one's sleeves technically,
to actually understand and be able to make sound decisions and
recommendations across a wide range of tools and libraries, as well as
a fair amount of just broad ongoing social interaction with the
haskell community to sound out prospective contributors. This is not
the same as a more official process of "going to groups and seeing
what they need" -- if they were well enough organized and led to tell
you directly what they need, they would be in a better position to
procure it to begin with. It is a creative process, of discovering
what needs to happen, on the basis of wide, if sometimes shallow,
participation in a range of discussions across the board. And it needs
to be coupled with an overall technical vision of the key things,
ecosystem-wide, that need the most attention to stay on track, or
which could, with a little properly directed effort, really take off
to be much more important. Well placed nudges can be more effective
than big proclamations, but the art of knowing what to nudge requires
a lot of background, experience, and prior interaction. A lot of this
is not only telling people what to do, but leading by example --
starting to contribute to some project to set a template of how others
can, initiating some process and then turning it over to others who
joined, etc.
*The Big Picture*
In my ideal world, a person in this role would also have at least two
more purely technical people whose time they could direct -- so they
could provide not only broad leadership of volunteers, but be able to
send someone to "throw a couple days" at this or that project to
unstick a particular logjam, ensure a PR had sufficient review, go add
some tests to finish off someone else's abandoned "90%" PR, spend a
week researching a topic to come back with a more concrete technical
plan, etc. In this sense these people wouldn't just be "contractors
working on tickets" but they'd be force multipliers for the CTO
themselves -- directed to work on the "right things" to enable others.
In the broad, the vision can be IDE tooling, new developer experience,
compilation performance, ecosystem stability, security features,
whatever. In the medium-narrow, this will always entail enabling and
directing contributions from volunteers. In this sense then, donations
don't go to this or that big ticket feature -- they go towards helping
the entire Haskell apparatus hang together coherently and develop.
More people submitting patches are nice, more people able to accept
them is even better, but even more important than that is ensuring we
have those maintainers, sourcing them, developing them, helping them,
and figuring out what resources can be provided to make their lives
easier and multiply their productivity. And again, no matter which
particular direction the HF prioritizes, doing it via this mechanism
is the key way it can make a difference -- taking high level technical
responsibility so it can empower and enable a much broader group of
people.
In our discussion on Thursday (Dec 2), Richard posed to me the
question of if the HF was better suited if it just hired a series of
contractors to work on tickets, or if it devoted resources as well to
a high level technical (i.e. CTO) hire. I want to motivate the latter,
based on my understanding of what the HF was intended to do (as
described and motivated to me) from its conception, as well as the
history of some prior, defunct attempts (notably the Industrial
Haskell Group), and finally the experience of the last year or so of
HF existence.
*HF Must Work with Modest Resources*
The financial resources available to the HF are relatively modest. We
understand that outside of core work, the bulk of development done on
the Haskell ecosystem (including core work on GHC, build tools, ides,
etc) is necessarily going to have to continue to come from volunteer
contributors or in-kind donations of development time from companies
-- further, I would not wish to change this, as it would too much
centralize the ongoing health of the Haskell world on one source of
support and funding. Hiring contractors to handle individual tickets
is a route at most to incremental improvements, and relatively small
ones at that -- in particular they will just be individual
contributors in a sea of other contributors. Further, it poses the
problem of picking which tickets to work on -- too large and there's a
high risk factor (and significant expertise required), too small and
there's increasingly less point. Further, proposing and getting
consensus on these tickets, and motivating them sufficiently as "wins"
etc provides a significant time overhead, and also expectations of
detailed reporting, which creates more overhead. Companies
increasingly start seeing themselves as donating to get specific work
done, and then weighing that against their own ability to just hire
people to do the work they want themselves will invariably find the
latter more cost-effective. This is the "IHG trap," why it couldn't
scale up, and why it eventually became defunct.
*Technical Leadership Provides a Force Multiplier*
The value proposition of the HF was precisely that it would not be
"IHG 2.0" but instead focus on being a force multiplier. In the
current state of the Haskell ecosystem there are a lot of enthusiastic
and willing contributors. What many core projects lack is
coordination, direction, and guidance (which are necessary aspects for
e.g. communication and onboarding as well). Many libraries are in
"maintenance update only" mode or semi-abandoned. There are trackers
with far too many languishing PRs, feature requests without a full
spec, half-finished discussions left fallow, etc. The problem is not
the will to contribute -- it is that there is not enough focus on
fostering and enabling contributions, because of lack of direction.
People don't lack ideas or will, they get dispirited because there is
nobody to say "yes, if you proceed, I will help you find answers to
problems you encounter, and work to make sure this is resolved, and
ideally merged," or nobody to say "out of all these issues, here are
five that you might be suited for, and also which definitely would be
welcomed if they were accomplished." More individual contributors,
paid or otherwise, doesn't help resolve this directionlessness and
logjam. There are people who could, and have, volunteered to help lead
some of this. But 1) they often don't feel empowered to step up as
leads if they haven't already been longtime contributors and 2) the
time commitment involved in ongoing attention is much greater than
occasional focused pull requests, the level of responsibility for
merging a PR and making a release is much different than making a PR,
etc.
*Technical Leadership Requires Attention and Depth*
What is needed both at the project level, and ecosystem level, is
technical leadership that can take responsibility for identifying
these logjams, sorting through the wide range of tickets and
highlighting the most important ones with broadest impact, and
highlighting them to source contributors (if you just say "Haddock
needs help" you won't get many takers -- if you motivate "here are
three tickets that would really be welcome and neat!" you stand much
better odds), anticipating which arenas are most languishing and in
need of attention, providing or sourcing guidance to help contributors
who get stuck, and empowering individual contributors to themselves
step up as maintainers (a leap people don't take unless pushed). A key
element here in motivating contributors is also responsiveness – being
able to answer tickets or PRs in a timely fashion so nobody feels
their work is languishing (which is tremendously demotivating for any
future work or interaction).
This requires a fair amount of rolling up one's sleeves technically,
to actually understand and be able to make sound decisions and
recommendations across a wide range of tools and libraries, as well as
a fair amount of just broad ongoing social interaction with the
haskell community to sound out prospective contributors. This is not
the same as a more official process of "going to groups and seeing
what they need" -- if they were well enough organized and led to tell
you directly what they need, they would be in a better position to
procure it to begin with. It is a creative process, of discovering
what needs to happen, on the basis of wide, if sometimes shallow,
participation in a range of discussions across the board. And it needs
to be coupled with an overall technical vision of the key things,
ecosystem-wide, that need the most attention to stay on track, or
which could, with a little properly directed effort, really take off
to be much more important. Well placed nudges can be more effective
than big proclamations, but the art of knowing what to nudge requires
a lot of background, experience, and prior interaction. A lot of this
is not only telling people what to do, but leading by example --
starting to contribute to some project to set a template of how others
can, initiating some process and then turning it over to others who
joined, etc.
*The Big Picture*
In my ideal world, a person in this role would also have at least two
more purely technical people whose time they could direct -- so they
could provide not only broad leadership of volunteers, but be able to
send someone to "throw a couple days" at this or that project to
unstick a particular logjam, ensure a PR had sufficient review, go add
some tests to finish off someone else's abandoned "90%" PR, spend a
week researching a topic to come back with a more concrete technical
plan, etc. In this sense these people wouldn't just be "contractors
working on tickets" but they'd be force multipliers for the CTO
themselves -- directed to work on the "right things" to enable others.
In the broad, the vision can be IDE tooling, new developer experience,
compilation performance, ecosystem stability, security features,
whatever. In the medium-narrow, this will always entail enabling and
directing contributions from volunteers. In this sense then, donations
don't go to this or that big ticket feature -- they go towards helping
the entire Haskell apparatus hang together coherently and develop.
More people submitting patches are nice, more people able to accept
them is even better, but even more important than that is ensuring we
have those maintainers, sourcing them, developing them, helping them,
and figuring out what resources can be provided to make their lives
easier and multiply their productivity. And again, no matter which
particular direction the HF prioritizes, doing it via this mechanism
is the key way it can make a difference -- taking high level technical
responsibility so it can empower and enable a much broader group of
people.
Simon Peyton Jones
Dec 16, 2021, 10:49:38 AM12/16/21
to Richard Eisenberg, Haskell Foundation Board
I agree with everything Gershom writes.
And yet, having a CTO carries an opportunity cost. At the HF's current scale, having two senior FTEs means that much of our sponsorship is spent on HF staff. I think it would give a much stronger sense of "our Foundation" if we were to spend a larger fraction of our budget directly in the community. Contractors possibly, but also directly and visibly funding our open-source contributors. E.g there is a proposal to fund a GHC Devops person which is hugely welcome; but it would be great if we could offer direct financial support to Cabal, Stack/Stackage, HLS... And then there is Chris Smith's proposal for a HF small-grants programme.
Spending money wisely takes time and energy. But perhaps not all that much: e.g if we simply gave the Cabal folk a grant, maybe they could manage the specifics of how to spend it most effectively.
My ideal HF has a very lightweight central org, with most of the oomph happening in the community. Yes, that central org needs critical mass. (Eg you can' have 0.5 of an executive directory.) Yes, all the things Gershom says make sense. Everything is a balance of judgement.
Partly this is psychological -- what will make people feel that the HF is their Foundation, working in their community, to improve their language? Those feelings are admittedly not the end-goal of the HF, but if we can successfully create that sense of ownership, I think it will be a lot easier to achieve our goals.
If I read the budget aright, 2022 looks like
- Income $660k
- HF central staff expenditure (1FTE) $170k
That is a good look. If we double central staff we get central staff expenditure of $340k. That's not terrible, but it's less good. And hiring a CTO is an inelastic, ongoing commitment, so it's fundamentally less flexible.
I'm not expressing a clear opinion on this topic. I'm more just trying to balance Gershom's excellent observations with other thoughts that we should consider.
Simon
--
You received this message because you are subscribed to the Google Groups "Haskell Foundation Board" group.
To unsubscribe from this group and stop receiving emails from it, send an email to board+un...@haskell.foundation.
To view this discussion on the web visit https://groups.google.com/a/haskell.foundation/d/msgid/board/010f017dc374b9c8-0d32fbae-49ae-4542-9e60-9d5c53d0a12d-000000%40us-east-2.amazonses.com.
Chris Dornan
Dec 16, 2021, 11:15:46 AM12/16/21
to Simon Peyton Jones, Richard Eisenberg, Haskell Foundation Board
I agree with everything Simon writes! Except I would go even further. Having an almighty CTO swooping in and solving all the problems is just likely to create as many problems as it solves — each intervention is likely to create as many problems as it solves as it is likely to disrupt some group or other. Focusing on enabling the community to fix things seems a better approach to me.
Chris
To view this discussion on the web visit https://groups.google.com/a/haskell.foundation/d/msgid/board/CAJKmMz9bcfnW-WjO0JpMCs73Z7hYu9F9cJMnbLK6FhD0J%2BeAQg%40mail.gmail.com.
José Pedro Magalhães
Dec 16, 2021, 11:23:01 AM12/16/21
to Chris Dornan, Simon Peyton Jones, Richard Eisenberg, Haskell Foundation Board
Separately: is the decision of whether to hire a CTO or not something that sits with the board, or with the executive team (CEO)?
Thanks,
Pedro
To view this discussion on the web visit https://groups.google.com/a/haskell.foundation/d/msgid/board/B6623B6A-5754-4F40-B7E9-E22E19746554%40chrisdornan.com.
Alexander Bernauer
Dec 16, 2021, 5:22:28 PM12/16/21
to Haskell Foundation Board
Hi
The "one throat to choke" model (as Ryan likes to call it :) ) means that hiring a CTO is the ED's decision. But this is only because that's how the board has decided to structure the organization. We could change that structure. And we could force the hire of a CTO. But I would advise against this at this time.
Regards,
Alex
To view this discussion on the web visit https://groups.google.com/a/haskell.foundation/d/msgid/board/CA%2BZFbn97%3DO88T8C1iLDXRNPtwZ86yFGHAGnREvOwj37Gxnjkqg%40mail.gmail.com.
Simon Peyton Jones
Dec 16, 2021, 6:26:47 PM12/16/21
to José Pedro Magalhães, Chris Dornan, Richard Eisenberg, Haskell Foundation Board
Separately: is the decision of whether to hire a CTO or not something
that sits with the board, or with the executive team (CEO)?
My instinct would be this: the ED proposes, and the board ratifies.
Reason: making a $200k/yr
commitment
covering an indefinite future period on an income stream of $600k is a strategic, not a tactical move. I would expect the ED to positively want to get the board's agreement about a major strategic commitment like this, both to share the accountability for it, and to get the benefit of board's advice about the pros and cons.
But I'd expect the ED to initiate and lead that discussion.
Maybe it is too blurry where the lines are. Andrew needs to know what he can decide and act on, at his own discretion, and what he should consult the board about. Andrew, if more clarity about that would help, I'm sure we can provide it.
(E.g. we could say "any one-off (i.e. non-recurrent) commitment, within the agreed budget, of less than $50k, can be decided by ED".) But it may not be a problem in practice.
Simon
Chris Dornan
Dec 17, 2021, 12:30:31 AM12/17/21
to Simon Peyton Jones, José Pedro Magalhães, Richard Eisenberg, Haskell Foundation Board
To me it is obvious — the ED should get sign-off from the board for any hires. And if we have learned anything it is that the ED should be responsible for the hires that he or she is going to then manage.
Chris
Richard Eisenberg
Dec 17, 2021, 4:51:49 PM12/17/21
to Haskell Foundation Board
> On Dec 17, 2021, at 12:30 AM, Chris Dornan <ch...@chrisdornan.com> wrote:
>
> the ED should get sign-off from the board for any hires.
Richard
Simon Peyton Jones
Dec 17, 2021, 6:39:01 PM12/17/21
to Richard Eisenberg, Haskell Foundation Board
I just want to voice polite disagreement here. We're still small, and so
any hire is a significant portion of our budget. We have now approved a
budget with a technical line item bigger than the size of a salary. As
long as the hire fits within those parameters, I think our ED is free to
hire whom he'd like.
I think there is a big difference between recurrent and non-recurrent expenditure.
We authorise a budget for a year. Expenditure within that budget is fine. But a hire that eats up 30% of the budget, and is recurrent (doing so for every subsequent year) is a different matter.
As I said earlier in this thread, I would expect any ED to positively want to consult the board about a recurrent commitment on that scale. I don't see this as micro-management (it's a macro decision; and since it is macro there are not going to be a lot of them); rather as a desire to be of one mind when making decisions that will bind us for multiple years.
I'd be happy to hear what Andrew thinks. My intent is to be supportive of his proposals, not to interfere with them.
Simon
--
You received this message because you are subscribed to the Google Groups "Haskell Foundation Board" group.
To unsubscribe from this group and stop receiving emails from it, send an email to board+un...@haskell.foundation.
To view this discussion on the web visit https://groups.google.com/a/haskell.foundation/d/msgid/board/010f017dca613703-f2aa9b5d-3f4a-49fb-86b4-882642ce95d3-000000%40us-east-2.amazonses.com.
Andrew Boardman
Dec 30, 2021, 1:51:14 PM12/30/21
to Simon Peyton Jones, Richard Eisenberg, Haskell Foundation Board
Hi all,
One of the reasons that I did not add a commitment to the budget for 2022 to include a funded CTO position was to ensure that we can have a separate conversation that weighs the opportunity cost as well as the benefit. I am talking to a potential candidate, but as has been discussed it is more about defining the position, responsibilities, and expectations clearly and making sure the benefit the Haskell community gets outweighs the same resources being used on a variety of priorities.
I agree 100% with Simon on the difference between a recurring expenditure and one-time expenses. It is totally reasonable for there to be a budget line item for recurring expenses that I could potentially hire from, but that is not what has been approved. I definitely would want the Board to be excited and happy with any choice I made about the CTO, and would involved at least a few interested members in the process, but I think the process goes:
1. Identify the cost:benefit for the position vs how we would spend that money otherwise by defining the position crisply.
2. Get approval from the Board for allocating the budget (primarily from the approved technical agenda line item) to the recurring position.
3. Find the right person with the input of the interested Board members.
4. Make the final choice and hire them on.
We have started #1.
Thank you,
-- Andrew
To view this discussion on the web visit https://groups.google.com/a/haskell.foundation/d/msgid/board/CAJKmMz-j%3DoNdBvM8Yy5j9PH9%3D5V98pcHMwDrxL21NY2sKKPaEA%40mail.gmail.com.
Julian Ospald
Jan 7, 2022, 2:49:24 AM1/7/22
to Haskell Foundation Board, and...@haskell.foundation, li...@richarde.dev, Haskell Foundation Board, simon.pe...@gmail.com
Hi,
my fear as a community contributor is that the Haskell Foundation, without a CTO, would simply become yet another bikeshedding body within the Haskell community and lose much of its positive reputation it currently has.
The main problem of the Haskell community is not lack of funding, as I argued in a previous thread here before. It's lack of communication, lack of focused efforts, lack of guidance, lack of supporting contributors.
It is my understanding, that the Haskell Foundation itself still has issues with communication as well. These issues will just become worse if the communication with the technical community sits on the shoulders of board members or contributors, who do this stuff on the side.
The reason so much stuff is stuck is exactly as Gershom described: logjam, unreviewed PRs, a CLC that has just been rebooted... and I would add that it's also quite often political. Funding will not fix any of those.
HF needs to stay on top of what's going on in the community. That alone is a full-time job.
The impact of a HF CTO is hard to measure, but it's massive.
Cheers,
Julian
Tom Ellis
Jan 8, 2022, 9:58:10 AM1/8/22
to bo...@haskell.foundation
Thank you very much Julian. I was wondering if you could elaborate a
bit about how you envisage the role a CTO would play in improving
communication, focused efforts, guidance and supporting contributors.
It would be excellent to improve all those things of course! But at
the moment they are stated as abstract goals. Concrete examples
(realistic, but not necessarily *real*) would go a long way to making
the case for hiring a CTO.
Thanks,
Tom
On Thu, Jan 06, 2022 at 11:49:23PM -0800, Julian Ospald wrote:
> my fear as a community contributor is that the Haskell Foundation, without
> a CTO, would simply become yet another bikeshedding body within the Haskell
> community and lose much of its positive reputation it currently has.
>
> The main problem of the Haskell community is not lack of funding, as I
> argued in a previous thread here before. It's lack of communication, lack
> of focused efforts, lack of guidance, lack of supporting contributors.
>
> It is my understanding, that the Haskell Foundation itself still has issues
> with communication as well. These issues will just become worse if the
> communication with the technical community sits on the shoulders of board
> members or contributors, who do this stuff on the side.
>
> The reason so much stuff is stuck is exactly as Gershom described: logjam,
> unreviewed PRs, a CLC that has just been rebooted... and I would add that
> it's also quite often political. Funding will not fix any of those.
>
> HF needs to stay on top of what's going on in the community. That alone is
> a full-time job.
>
> The impact of a HF CTO is hard to measure, but it's massive.
>
bit about how you envisage the role a CTO would play in improving
communication, focused efforts, guidance and supporting contributors.
It would be excellent to improve all those things of course! But at
the moment they are stated as abstract goals. Concrete examples
(realistic, but not necessarily *real*) would go a long way to making
the case for hiring a CTO.
Thanks,
Tom
On Thu, Jan 06, 2022 at 11:49:23PM -0800, Julian Ospald wrote:
> my fear as a community contributor is that the Haskell Foundation, without
> a CTO, would simply become yet another bikeshedding body within the Haskell
> community and lose much of its positive reputation it currently has.
>
> The main problem of the Haskell community is not lack of funding, as I
> argued in a previous thread here before. It's lack of communication, lack
> of focused efforts, lack of guidance, lack of supporting contributors.
>
> It is my understanding, that the Haskell Foundation itself still has issues
> with communication as well. These issues will just become worse if the
> communication with the technical community sits on the shoulders of board
> members or contributors, who do this stuff on the side.
>
> The reason so much stuff is stuck is exactly as Gershom described: logjam,
> unreviewed PRs, a CLC that has just been rebooted... and I would add that
> it's also quite often political. Funding will not fix any of those.
>
> HF needs to stay on top of what's going on in the community. That alone is
> a full-time job.
>
> The impact of a HF CTO is hard to measure, but it's massive.
>
Julian Ospald
Jan 11, 2022, 4:30:36 AM1/11/22
to Haskell Foundation Board, Tom Ellis, bo...@haskell.foundation
Let's start with things HF should avoid:
1. the failed unified installer proposal
2. recent thread here about crypto libraries https://groups.google.com/a/haskell.foundation/g/board/c/68K8jlYChFQ
3. alienate community contributors
These things can happen easily, when there's no one around who has the time to deal with all of this full-time.
Thus, a CTO would:
1. forge relationships with the technical community: through support, patches, looking for contributors. Not just fancy talk and funding, but also actual code.
2. connect community forces: contact parties, connect them, mediate
3. identify pain points in the ecosystem
4. drive technical HF projects
And do all of that in a manner that is inclusive, doesn't cause political incidents and maintains an image of the HF being a supportive, not a demanding force.
Cheers,
Julian
Tom Ellis
Jan 11, 2022, 5:49:22 AM1/11/22
to bo...@haskell.foundation
Thanks Julian,
Strongly agreed that HF should proactively avoid miscommunication and
alienating community contributors. Personally speaking, the role I
would like HF to play is that of amplifying the community, giving
community members assistance so that they can do even more of the
great things that they already do, and want to do. I believe fellow
members of the HF share my view. Naturally the best means of
implementing the HF's amplifying role will always be subject to
discussion.
I can't see clearly one way or another whether a CTO role per se is
the best means for achieving that aim. The Haskell community is
replete with technical competence and I don't think any of the three
problems you list below have occurred because of difficulty with
*technical* organisation. Solving those problems requires strong
people skills, the ability to listen, empathise, understand people's
experience, besides the technical aspects, and to plot a course
forward that takes into account the feelings of a broad swathe of the
community. On the other hand the four CTO tasks you list *do* require
high technical competence.
(I should add that our outgoing CTO Emily performed admirably on both
interpersonal and technical aspects.)
So I'm not sure whether we need a CTO with strong people skills or a
community-organiser with strong technical skills, or both, or
something else.
I welcome your, or anyone else's, thoughts.
Tom
On Tue, Jan 11, 2022 at 01:30:35AM -0800, Julian Ospald wrote:
> Let's start with things HF should avoid:
>
> 1. the failed unified installer proposal
> 2. recent thread here about crypto libraries
> https://groups.google.com/a/haskell.foundation/g/board/c/68K8jlYChFQ
> 3. alienate community contributors
>
> These things can happen easily, when there's no one around who has the time
> to deal with all of this full-time.
>
> Thus, a CTO would:
>
> 1. forge relationships with the *technical* community: through support,
Strongly agreed that HF should proactively avoid miscommunication and
alienating community contributors. Personally speaking, the role I
would like HF to play is that of amplifying the community, giving
community members assistance so that they can do even more of the
great things that they already do, and want to do. I believe fellow
members of the HF share my view. Naturally the best means of
implementing the HF's amplifying role will always be subject to
discussion.
I can't see clearly one way or another whether a CTO role per se is
the best means for achieving that aim. The Haskell community is
replete with technical competence and I don't think any of the three
problems you list below have occurred because of difficulty with
*technical* organisation. Solving those problems requires strong
people skills, the ability to listen, empathise, understand people's
experience, besides the technical aspects, and to plot a course
forward that takes into account the feelings of a broad swathe of the
community. On the other hand the four CTO tasks you list *do* require
high technical competence.
(I should add that our outgoing CTO Emily performed admirably on both
interpersonal and technical aspects.)
So I'm not sure whether we need a CTO with strong people skills or a
community-organiser with strong technical skills, or both, or
something else.
I welcome your, or anyone else's, thoughts.
Tom
On Tue, Jan 11, 2022 at 01:30:35AM -0800, Julian Ospald wrote:
> Let's start with things HF should avoid:
>
> 1. the failed unified installer proposal
> 2. recent thread here about crypto libraries
> https://groups.google.com/a/haskell.foundation/g/board/c/68K8jlYChFQ
> 3. alienate community contributors
>
> These things can happen easily, when there's no one around who has the time
> to deal with all of this full-time.
>
> Thus, a CTO would:
>
> patches, looking for contributors. Not just fancy talk and funding, but
> also actual code.
> 2. connect community forces: contact parties, connect them, mediate
> 3. identify pain points in the ecosystem
> 4. drive technical HF projects
>
> And do all of that in a manner that is inclusive, doesn't cause political
> incidents and maintains an image of the HF being a supportive, not a
> demanding force.
>
> also actual code.
> 2. connect community forces: contact parties, connect them, mediate
> 3. identify pain points in the ecosystem
> 4. drive technical HF projects
>
> And do all of that in a manner that is inclusive, doesn't cause political
> incidents and maintains an image of the HF being a supportive, not a
> demanding force.
>
> On Saturday, January 8, 2022 at 2:58:10 PM UTC Tom Ellis wrote:
>
> > Thank you very much Julian. I was wondering if you could elaborate a
> > bit about how you envisage the role a CTO would play in improving
> > communication, focused efforts, guidance and supporting contributors.
> > It would be excellent to improve all those things of course! But at
> > the moment they are stated as abstract goals. Concrete examples
> > (realistic, but not necessarily *real*) would go a long way to making
> > the case for hiring a CTO.
> >
>
> > Thank you very much Julian. I was wondering if you could elaborate a
> > bit about how you envisage the role a CTO would play in improving
> > communication, focused efforts, guidance and supporting contributors.
> > It would be excellent to improve all those things of course! But at
> > the moment they are stated as abstract goals. Concrete examples
> > (realistic, but not necessarily *real*) would go a long way to making
> > the case for hiring a CTO.
> >
Reply all
Reply to author
Forward
0 new messages