- hf-discuss - Haskell.org

Retiring the HF mailing lists
by Richard Eisenberg 26 Apr '21

26 Apr '21

Hi HF fans! The HF has been busy piecing itself together, and we are now proud to report several technical projects in the works. Our Executive Director Andrew Boardman will be providing another update later this week with the details. One of our tasks was in just figuring out how to organize ourselves. This is being done on the repo at https://gitlab.haskell.org/hf/meta <https://gitlab.haskell.org/hf/meta>. That repo contains documents, ratified by the Board of the HF, that describe our way of doing business. You may be interested in https://gitlab.haskell.org/hf/meta/-/blob/main/communication.md <https://gitlab.haskell.org/hf/meta/-/blob/main/communication.md>, which describes our chosen ways of communicating. We have settled on the following: * Communication among the board and from the wider community to the board happens at the mailing list board(a)haskell.foundation <mailto:board@haskell.foundation>. Archives are at https://groups.google.com/a/haskell.foundation/g/board <https://groups.google.com/a/haskell.foundation/g/board>. * Communication from the HF to the community and communication among community members happens in the Haskell Foundation category of the Haskell Discourse instance: https://discourse.haskell.org/c/haskell-foundation/11 <https://discourse.haskell.org/c/haskell-foundation/11> * There is also a public Slack instance at haskell-foundation.slack.com <http://haskell-foundation.slack.com/>. Email contact(a)haskell.foundation <mailto:contact@haskell.foundation> to get an invite. Given these other communications methods, these lists, hf-discuss(a)haskell.org <mailto:hf-discuss@haskell.org> and hf-announce(a)haskell.org <mailto:hf-announce@haskell.org>, are going to be retired. Their functions are replaced by the facilities on Discourse. Note that Discourse allows you to subscribe only to a particular category, so you can limit Discourse notifications to include only HF-related communication, if you so choose. Thanks for your interest in the HF, and see you on Discourse! Richard (chair of HF board)

1 0

How can I make a PR to the website?
by Tom Ellis 04 Jan '21

04 Jan '21

Hello, There are a number of small changes I would like to suggest to https://haskell.foundation. In the spirit of "be the change you want to see in the world", rather than request someone else to make changes I would like to make my suggestions as PRs to the website source. Is the website source available somewhere? (Search engines only give hits for the Haskell package called "foundation", sadly.) Tom

4 5

Do something about Cabal?
by Ignat Insarov 23 Dec '20

23 Dec '20

# Do something about Cabal? Hello. Cabal is the second most used tool in Haskell after GHC. It has many problems. It may be noticed that there is one and a half developers working on it. This is clearly not enough to address these problems. I propose that this is a good place to invest in. ### Problems I have in mind: * Poor communication, lack of open source development process. The whole Cabal–Stack schism appears to be an outcome of poor communication. One of the leading developers of Cabal is even banned from participation somewhere in Stack circles.[1] Personally, I reported several issues to Cabal and every single time it resulted in sadness. Observe a vicious circle: core developers are overworked ⇒ they are being unfriendly ⇒ there are fewer contributors ⇒ core developers are overworked. I have no hard evidence but it appears that presently, more people that strive to improve the Haskell build experience are outside the Cabal cabal than are inside. * User experience is an afterthought. Cabal's user experience is horrifying. A collection of complaints is being compiled elsewhere.[2] There are also bugs being opened to Cabal because of this, requiring triage and therefore wasting the precious time of the few overworked developers. Stack is much more friendly — this shows by example that the user experience problem is not inherent and may be solved. It is ordinary to receive output like this: ``` % cabal run example-executable Warning: The package list for 'hackage.haskell.org' is 84 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... cabal: Could not resolve dependencies: [__0] trying: example-0.1.0.6 (user goal) [__1] next goal: opaleye (dependency of example) [__1] rejecting: opaleye-0.7.1.0, opaleye-0.7.0.0 (constraint from project config TODO requires ==0.6.7006.1) [__1] rejecting: opaleye-0.6.7006.1 (conflict: example => opaleye^>=0.7) [__1] skipping: opaleye-0.6.7006.0, opaleye-0.6.7005.0, opaleye-0.6.7004.2, opaleye-0.6.7004.1, opaleye-0.6.7004.0, opaleye-0.6.7003.1, opaleye-0.6.7003.0, opaleye-0.6.1.0, opaleye-0.6.0.0, opaleye-0.5.4.0, opaleye-0.5.3.1, opaleye-0.5.3.0, opaleye-0.5.2.2, opaleye-0.5.2.0, opaleye-0.5.1.1, opaleye-0.5.1.0, opaleye-0.5.0.0, opaleye-0.4.2.0, opaleye-0.4.1.0, opaleye-0.4.0.0, opaleye-0.3.1.2, opaleye-0.3.1, opaleye-0.3, opaleye-0.2, opaleye-0.6.7002.0, opaleye-0.6.7001.0, opaleye-0.6.7000.0, opaleye-0.5.2.1, opaleye-0.3.1.1 (has the same characteristics that caused the previous version to fail: excluded by constraint '^>=0.7' from example) [__1] fail (backjumping, conflict set: example, opaleye) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: opaleye, example ``` There are so many things that are wrong here. Even a sneaky _«to do»_ remark. If you wonder, in this case the solution is to remove and re-generate `cabal.project.freeze`. Even the name of the program — it is actually _«cabal-install»_ — is incomprehensible, it should be re-branded to Cabal, which is how everyone calls it anyway. * Features are not being introduced. There is no reason for two build tools to exist. The killer feature of Stack — snapshots — should be supported by Cabal. Possibly Cabal itself should be refactored and split so that there are separate tools for packaging, version resolution and human interaction — I do not know. But certainly the way things are presently is a waste of developer effort and a source of confusion for everyone. ### My proposition, in particular. * Ask all the people that show compassion to the cause of a great Haskell build tool to unite and work together on a better Cabal. This includes the developers of Stack and everyone that expressed unhappiness with the current state of Cabal. These people should be seen as a blessing, not as an obstacle. * Put in place a clear process for contributing and decision making, so that it does not come down to the privileged opinion of one of the core developers. * Make a model of user experience that Cabal should conform to, and make conformance a priority. Surely there are among us people that know a thing or two about user experience — call for them to step forward. Every issue that stems from misunderstanding, re-assign to the model instead of closing. * Merge the support of Stackage snapshots into Cabal. Ask the core developers of Stack to join the effort. Transition from Stack to Cabal should be one well discoverable command that just works. I realize that this letter is largely an opinion piece. You can also see it as an _«ideal piece»_. Without an ideal, without a vision, we are stuck with the present. I do not insist that my vision is the best. But the present reality is not the best vision either. I propose, foremost, that we work and fight for a better future. [1]: https://github.com/commercialhaskell/stackage/issues/4472 [2]: https://github.com/tomjaguarpaw/tilapia/issues?q=is%3Aissue+is%3Aopen+cabal

12 14

Volunteer On-Boarding Track: Contributor Attributions
by Rebecca Skinner 13 Nov '20

13 Nov '20

Hi everyone, During today's contributor on-boarding discussion we discussed, among other things, the ways that the Rust community has worked toward encouraging people to contribute to its ecosystem through making an effort toward recognizing contributors, and how the HF might be in a position to offer something similar in the haskell ecosystem. I wanted to open a thread to start discussing some of the options for how we might consider approaching something like that, and ultimately whether it's something that we think we ought to be doing. First, a bit of background. I'm going to summarize the main points I took away from the discussion, and hopefully if I've missed something, or gotten something wrong, someone can jump in and correct me on the details here. One of the things that the Rust community wanted to do was to give people some recognition for their contributions in a public way that was a bit more visible than just looking at the commit history in github, so they borrowed an idea from the Ruby community and started collecting a list of names of all of the people who had contributed commits for any given release of Rust. These were published on their website along with each release. It seems that this was quite motivating for at least some contributors, who were quite keen to have their names listed publicly and have something to point out to highlight their contributions. There were a few challenges the Rust folks encountered, in particular: 1. As the project started to divide up into many smaller repositories, the tools they were using to collect contributor names didn't scale and some people were disappointed to see that they were left out of the acknowledgements 2. People's names can change for various reasons, and it can be some overhead to deal with keeping older announcements updated 3. There isn't necessarily a single clear and non-controversial criteria for figuring out what commits should be included, especially if you are ranking commits in some way In spite of the challenges, the Rust community seems to have gotten a lot of value out of attribution, and I think it could be a great example of the kind of the the HF could offer to the haskell community to try to drive interest in contributions and get more people involved in the haskell ecosystem. It's the kind of thing that might not make a lot of sense for any given project to invest time in, but amortized over the entire haskell community it could drive more engagement and bring in contributors. It also helps us start building a reputation as a welcoming organization that is actively encouraging new contributors. Finally, as a relatively small greenfield project, it would be a good opportunity for us to get our feet we and start to establish norms and figure out how HF will go about this kind of work. I would propose that, if we wanted to go forward with this idea, we could approach it like this: 1. If we have some maintainers and interested contributors, we could start a new project that is affiliated with HF from the beginning. The project will aim to provide a generally flexible way of collecting and publishing contributor data. Although this would be in theory a stand-alone project, it would be developed with an eye toward the needs of HF. As an open source project however, anyone would be free to use this tool. 2. The HF uses this tool to generate and host an acknowledgements page to recognize contributors to any of the affiliated projects. This could be an opt-in or opt-out think for individual projects, but ideally it's just something nice that comes for free to any project that affiliates with HF. 3. We publicize the list and get the word out, and try to see whether this is doing what we want and getting more people excited to contribute to the ecosystem. This is a pretty rough set of ideas, so if anyone has any visions of how something like this could work, or reasons why they think we shouldn't do it at all, I hope you'll share your thoughts. ~Rebecca

1 0

Involving the grass routes in supporting the Foundation
by Carlton Mills 08 Nov '20

08 Nov '20

Good afternoon, You could provide an ability for starving students, retirees, and ordinary peoples to contribute to the Foundation. What is needed for an individual to go to a web site and arrange for $5.00/month to be taken out of her checking account. Hopefully a large number will join; this would give the Foundation a lot of credibility. Administratively one would need a 401(c) entity in the US so we could deduct our contributions. You could say all these contributions will go directly to increasing the Foundation’s endowment or to paid research/documentation/… Use the contributions from big entities to pay for administration. That way individuals can feel that their money is being used productively. (I am told that the Red Cross does this for disaster relief: 100% of the contributions for a specific disaster go towards the victims -nothing to overhead. It would be nice if there was a huge flood of cash from the base. Thank you for your attention,-Carlton Mills, Urbana, IL

1 0

Incentives for contributions, project ideas
by Tillmann Vogt 08 Nov '20

08 Nov '20

Dear fellow Haskell programmers, I just read the whitepaper. Quote: "Haskell Foundation will identify a list of technical goals that will ease adoption and improve Haskell use in production. We have established an initial agenda and are seeking to refine it as we go forward. As HF evolves, we will engage technical discussion in a transparent way, with input from the community." For me improvements are about - finding the biggest pain points - efficient communication - incentives to fix problems There are a lot of places that are embarassing. For example in Ubuntu, if I enter "haskell" into the search box of synaptics, I get "haskell-platform 2014". A programmer may think: "Is this language dead?" There are many projects that drown in open issues on github, where I really feal pity for the poor maintainer. We all don't have time. It could get better if we had - a good strategy on what to fix first - incentives - automation (I am working on something which I will announce soon) Here are some ideas how to fix this: Reporting of Error Messages, Lowering the barrier to report pain points ----------------------------------------------------------------------- A global variable set in bash that makes GHC send error messages anonymously to a central database. For example someone changes code and then thousands of people have the same problem, you know how urgent a fix is. All that would be needed is to ask people during installation if they want to allow this (opt in). Of course data has to be carefully accumulated so that it is really anonymous. Virtual Currency to incentivise fixing of Github/Gitlab issues -------------------------------------------------------------- Example problem: I am not smart enough to fix an issue in Cabal. I sit there one day, trying to understand Cabal. I don't get it and give up. I decide to work on an other issue and hope someone else will fix it eventually. Unfortunately it does not happen. Solution: For some problems I am smart enough to fix them. What if there would be a virtual currency that pays me for solving these issues. Depending on how important an issue is I would then invest my virtual coins to fix the cabal issue. Concrete implementation: A big table that lists Github/Gitlab (especially GHC) issues. Sortable after topic, urgency, bounty coins when it is fixed, ... A database with all e-mails that are currently on hackage, pepole on several mailing list get an initial amount of coins. New people only get initial coins when they have published code of a certain quantity and quality. A simple entry mask with your e-mail/github name, the link to the github/gitlab issue, bounty coins you are willing to spend if certain conditions are met Arguments against it: It's a little bit like capitalism against communism. In communism you have a board of leaders of the party. There are no incentives apart from making the ideology win and medals, like "hero of work" (the stars on github). I understand that there was no other way to do make Haskell happen but Open Source and volunteers. It would not be financable. And I also admit that the current board is really impressive. Capitalism on the other side is very problem focused, increases the idiviudal motivation, but makes people focused too much on the money. It could lead to messages like: Give me coins, or I don't fix the issue. But for this, A leader board could decide that you are punished if you talk about coins on github. If a first test works, virtual coins could be buyable with real money. This could be a source of income for the foundation. I would be willing to program this for free and open source. I am currently making a web page anyway. BTW you don't have to be nice, feel free to be negative and critical. - Tillmann Vogt

1 0