<div dir="ltr"><div>Hi everyone,</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>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</div><div>2. People's names can change for various reasons, and it can be some overhead to deal with keeping older announcements updated</div><div>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</div><div><br></div><div>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.</div><div><br></div><div>I would propose that, if we wanted to go forward with this idea, we could approach it like this:</div><div><br></div><div>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.</div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>~Rebecca<br></div></div>