Its okay, everyone is wrong about some things.

There were optimizations related to database triggers, these are probably responsible for the speedup.

https://github.com/LemmyNet/lemmy/pull/4696

Thank you :)

Nowadays I can easily handle all Github notifications within less than an hour. After the Reddit blackout there were so many notifications that I couldnt even read all the issues, let alone respond. So I had to unsubscribe from issue notifications for some months.

I was waiting for someone else to create a project like this. But it didnt happen so I had to write it myself when things became a bit calmer with Lemmy.

No schade-throwing, but I know how much effort it took to get Lemmy ready for production. Namely multiple years of fulltime work. Sublinks seems to have only volunteer contributors, so it will likely take even more time.

Or these people could learn Rust and contribute to the existing project. That would save years of duplicated effort. I personally knew zero Rust before starting to contribute to Lemmy, its really not that hard to learn.

I was a Java developer before starting to contribute to Lemmy. Didnt know anything about Rust, just wrote code and resolved compiler errors until things worked. Rust is definitely not as hard to learn as some people think.

Not true. And if you miss a feature why dont you help implementing it instead of complaining? Thats what open source is all about.

Thanks for the suggestions!

Create an ARCHITECTURE.md document explaining the overall architecture and different components of Lemmy. This would help new contributors quickly familiarize themselves with the codebase.

The documentation has some info about the architecture as well as how to start contributing. Is there anything particular missing, or do people not find these docs?

Publish a public roadmap with milestones and release plans. This gets people excited about the project’s direction and motivates them to contribute.

As mentioned in the other comment, we will have a public roadmap once the NLnet milestones are finalized. Other than that the issues are up for grabs for anyone, so Im not sure what sense it would make to give them priorities.

Nightly builds enable contributors to test upcoming changes, offer feedback, stay actively involved in the project’s progress, iterate quickly on improvements, and foster a culture of continuous improvement.

These are available as :dev Docker images, and deployed to test servers at enterprise.lemmy.ml etc. Maybe this should be documented somewhere to let people know?

Implement a bounty system for critical or challenging issues to incentivize contributions. Some people who don’t want to contribute with a monthly subscription may prefer this kind of contribution.

Bounty systems dont work well in my experience. Usually the reward is too low to pay an actual dev salary, and then its still a hassle to get the money into your bank account. Plus there is no gurantee to get paid for your work, its always possible that someone else submits a solution just before you finish yours.

Create project swag (stickers, t-shirts, etc.) and distribute it to active contributors as a token of appreciation.

Good idea, though we dont really have the funds to pay for that. It was also suggested to sell swag to earn money for Lemmy, but havent gotten around to that yet. Do you by chance any good company to produce and sell this?

Institute a “Lemmy contributor mentorship or apprenticeship” program where experienced developers formally take up 1-2 promising new contributors under their wing.

Well if anyone opens a pull request we give feedback as part of the review process. And if anyone has questions we also answer them in the issue tracker or on Matrix. But in practice there seems to be little demand in this regard.

Live or recorded screencasts solving issues, similar to mentorships but instead of one-on-one it allows more people to feel engaged in the development process, and provide feedback in the case of live streams.

That seems to get more into entertainment, not what we want to do.

Host discussions about issues on Lemmy itself, as suggested in the blog post below. The voting and threads with nested comments make it easier to have productive conversations compared to GitHub. The community is here so you’ll get more contributions right away in the form of ideas and feedback.

We do have biweekly dev updates which are somewhat related. But discussing individual issues here would likely duplicate discussions from Github issues.

Yes Bevy has a big advantage because its a library, so everyone who uses it is a developer and is able to fix minor issues. In case of Lemmy only a small fraction of users are developers, and even less know Rust. I watched the video, but its not easy to take concrete suggestions and apply them to Lemmy. Maybe the community reviews for PRs would be a good idea to get people familiar with the codebase. It also mentions using a project board so we should consider that. Though Im not sure how to select issues for each milestone because again, everything is up for grabs.

Hmm not sure whats the context of that quote.

Sure being more welcoming to outside contributors sounds good. Do you have any concrete suggestions how to recruit and train them? We do have some community contributors, but they seem very limited by the amount of time they have for Lemmy after their fulltime job.

Once the new round of NLnet funding is finalized we will publish those milestones. However Im not sure if a backlog like the one you linked is really helpful, it would take a significant amount of time to manage for little benefit. After all every open issue on the Lemmy Github is up for grabs for anyone to implement it.

I agree that its good for redundancy to have another development team for Lemmy. However they will be busy for the next few years redoing all the work we have already done for Lemmy. It would be much more efficient if they simply forked the existing Rust code and implemented their desired features on top. That would also make it easy to merge their changes back into Lemmy.

I see that comment but somehow cant fetch it from lemmy.ml. Would you mind asking what exactly they mean by “toxic development community”? Its honestly the first time I heard something like this about Lemmy.

I actually talked with Jason (one of the Sublinks maintainers) a while ago, asking about the features he was missing from Lemmy. Turns out it was just one or two minor API changes that could be easily implemented, but he never even bothered to open an issue about it. I think they just have fun reimplementing Lemmy, but it would take at least multiple years to catch up with the current features of Lemmy. And by then Lemmy will of course have many more features and improvements. So I wouldnt expect that this ever becomes useful for production.

Having a different license for each user would cause too much complexity and fragmentation. It makes more sense to have a license per instance. This can already be configured and gets displayed under /legal. Then based on the legal info users can decide where to signup, and admins can decide which instances to federate with.

You can run Lemmy in allowlist mode so it only federates with instances that you trust.

It should be very easy to distinguish edits and deletes which were made within a few minutes or hours after writing a comment, from those made months or years later right around the reddit blackout.

Interesting. However in this case the plane came down vertically so the wings/engines would hit the ground beside the building. In case of the pentagon, the plane supposedly flew horizontally at ground level, so the wings should crash directly into the building.