SAoC announced, my thoughts on potential projects

Core D Development Statistics

• 11 bugs fixed
• 6 bugs and enhancement requests opened
• Bugs closed WONTFIX:
  • unstable operator overloading with comma expression
  • Template specializations don't work in nested scope
  • Bugs caused by using logical 'and' instead of bitwise 'and'
  • The precedence of the exponentiation operator ^^ is too high.
• Bugs closed INVALID:
  • in does not work as storage class where const scope does
  • Cannot do qualifier-overload with mixin template.
• 25 pull requests merged into the language: 22 into DMD and druntime and 3 into Phobos
• 2 pull requests merged into the website.

In the community

Community announcements

• Symmetry Autumn of Code 2023
• On Mir parts migration to DRuntime
• DasBetterR
• Get ready your Playstation 5 controllers

See more at the announce forum.

Symmetry Autumn of Code

You can see the announcement in the list before this section, but one thing it links to is the list or project ideas and I think it needs some new ideas.

Looking down the list, improving error messages is always a worthwhile project and could really benefit from someone doing a deep dive into how to do it well; a student could find it as educational as the users find it valuable.

But everything else on that first page ranges from outright impossible (sometimes tasking students with the impossible can be educational as they learn why it is impossible, and they can see how they react to a no-win scenario... but I don't think that's what SAoC aims to achieve) to questionable value (someone's random pet project that has little chance of upstream acceptance even if completed), to just plain boring. Boring things can bring value to the D community, no doubt about that, but what does it bring to the student? What skills can they take away from the work?

The SAoC pays out almost $9 / hour if everything goes as planned ($3000 / (20 hours / week * 17 weeks)), which isn't nothing.... but that's not even minimum wage across most the United States (value varies by region, of course, so your purchasing power parity may vary), so the primary value proposition to the participant (I've been using "student", since that is the target audience and where the economics lead, but the rules allow anyone so that's not necessarily true) is the experience points moreso than the cash. This is also the resume material: if they're at a job interview, and are asked "what did you learn from that and how will it help you with us?", let's help them have a strong answer.

Therefore, the projects that are likely to work best are the ones that can be done by a student and leaves them with some valuable knowledge to take with them. Doing boring drudgework that everyone knows how to do but just takes time isn't that valuable. Frankly, neither is taking a deep dive into the specifics of dmd's implementation, since so much of that also isn't going to carry over to other projects. You can learn a little about basic compiler design and maybe work on your skills in how to approach a new codebase, which has some value, but the returns for the participant are gonna diminish fast the more time they spend on it; most those benefits to the participant come in the first days or weeks, but the benefits for the D come in the latter weeks. A rational outcome of such a situation is, if the project is picked up, that it will be dropped after the first milestone right about the time the student has maximized their own return on investment.

I think only a handful of the projects on that list actually fall into the sweetspot of win/win, where D gets valuable work done that will be adopted longer term and the participant gets valuable experience and knowledge that they can find long term use of outside of D. (Ideally, of course, you'd keep them around inside D, but that's *more* likely to happen with the more value D brings them, and transferable skills are generally more valuable than non-transferable skills.)

Therefore, I think we need new ideas. Let's list the criteria for better ideas first:

• The project must teach something to the participant they can use outside D. It must impart general knowledge to them, not just project specifics.
• The project must be easy to deliver results to both sides in a limited time, while continuing to deliver results to both sides throughout the duration of the project period; it should be quick to get into and give mutual benefit right off the gate, and have stretch potential so there's incentive to keep going.
• Fills something D doesn't already have in the holistic ecosystem. Otherwise it is a wasted duplication for us.
• The result must easily transferable to existing D resources for long term use. Otherwise, it will almost certainly be abandoned by the end of the year and not actually deliver the promised value.

With that in mind, let me propose some of my own pet projects that might work. arsd lib contributions can easily be based in general knowledge rather than project specifics. They may be able to stand alone, minimizing barrier of entry in getting the code integrated, and once I adopt it, I'll take care of the module long term, provided it does something at least a little useful to me too. Such projects are also naturally flexible - once you get a little done, it is a little useful, and if you spend more time, you can make it more useful. Many of the same benefits of a phobos contribution without the downsides and limitations that has historically had.

A few ideas:

• Bringing simpledisplay and simpleaudio to better support Mac. D's ecosystem gets its native libs now native on another major platform. Author gets experience with the Apple APIs, primarily as a user, which is easily transferable to mobile dev jobs, but also a look under the hood and learns how they are similar and different to Windows and Linux apis in the process of integrating them into my existing apis.
• Adding accessibility APIs to minigui. Again, we get the improvements of the use, and the author gets to know how these things work on major operating systems, which can transfer to other jobs. However, since this would be fairly low level, it might not transfer as well as other projects; knowing freedesktop's AT-SPI2 dbus interfaces surely has some overlap, but often the same goal can be achieved in other applications by adding aria attributes to a website, etc. Still knowing the low level apis might be a unique value proposition for the participant!
• Your module here! I'm always open to contributions and that includes things that might not be considered useful by others. arsd includes an oldschool midi chip emulator, for example! Let's consider some outside-the-box concepts you might have. But, if it is of absolutely zero use to me, I probably will reject it, since I don't want to adopt something that I'll end up neglecting.

These are things I plan to do anyway at some point myself, I just don't know when I'll find the time. Having a SAoC participant help out I think would be a win/win/win/win (them, me, the D community, and Symmetry Investments all have potential gains from these things).