Lemmy maintainer

  • 2 Posts
  • 19 Comments
Joined 5 years ago
cake
Cake day: January 17th, 2020

help-circle









  • 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.



  • 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 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.