I’ve read this comment on lemmy’s github repository by sbordeyne:

I closed it cause I have no interest in having to battle dessalines on minor nitpicks. Feel free to take the branch and reopen the pull request.

My thought process was that since lemmy is open source, we should be free to add new features without having to battle over philosophies, which was made apparent to me with his reviews and very strong opinions over which features to greenlight and which features to debate at length over (see infinite scrolling, and this very issue which was only approved on the condition we make it a setting that is off by default). I just don’t have the energy to contribute and be challenged on every little thing, I’ll just remain a plain user of the platform and not bother contributing to the project anymore.

Originally posted by sbordeyne in #282 (comment)

Instead of contributing to a project where only @dessalines@lemmy.ml, lionirdeadman and @nutomic@lemmy.ml dictate what gets approved, why not make a fork with the settings most people agree on?

My stance is that I wouldn’t contribute to a project hosted on GitHub, or a project that considers a few opinions more important than the majority.

Controversial takes
dessalines doesn't want SEO so we get URLs for robots

It might makes sense for the semantic web, but IMO it really doesn’t add that much value… look at how silly this type of thinking has gotten w/ reddit: https://www.reddit.com/r/aww/comments/glenz4/cute_baby_bunnies_think_the_golden_retriever_is/

Its gotten to reddit/community/comments/post_id/weird_lengthened_post_name, when it should be just reddit/post/postid

_Originally posted by @dessalines@lemmy.ml in https://github.com/LemmyNet/lemmy/issues/875#issuecomment-652165036_

:::

In my opinion, open-source projects should follow a set of principles to ensure transparency, community engagement, and effective development. Here are some key points that encapsulate these principles:

  • Clear Decision-Making Process for Future Releases: Open-source projects should have a well-defined process for deciding what features and improvements make it into each release. This process should be documented and accessible to the community. (For example, you can read about how Discourse decides what goes into each release here).

  • Complaint-Driven Development: Embrace the concept of “complaint-driven development,” where user feedback and complaints guide the prioritization of issues and features to address.

  • Transparent Donation Management: Be open about how donation money is allocated. Implementing a bounty system can further enhance transparency, enabling contributors to work on specific tasks for financial rewards.

  • Inclusive Community Involvement: Encourage active participation from the community in brainstorming and voting on potential features before finalizing the project roadmap. Community input can be invaluable in shaping the project’s direction.

  • Public Roadmap: Maintain a publicly accessible roadmap that outlines what is planned for upcoming releases. This roadmap should include the status of each feature or enhancement to keep users informed.

  • User-Friendly Feature Request Process: Provide a public feature request forum where users can submit their ideas. Clearly outline the process for how these requests will be reviewed and prioritized, ensuring transparency in the decision-making.

  • Effective Communication Channels: Avoid using disorganized or private communication platforms for project-related discussions. Instead, opt for well-structured, publicly accessible channels that don’t require users to log in to access information.

  • Document with a Blog: Utilize a blog or similar documentation platform to keep users and contributors informed about important project updates, changes, and developments.

  • 1stTime4MeInMCU@mander.xyz
    link
    fedilink
    English
    arrow-up
    21
    ·
    edit-2
    1 year ago

    My opinion, hopefully I don’t get downvoted into oblivion lol: Rust is great for lots of things and its to be commended for forward thinking on so many neglected areas of software development from the last 20 years. I use it almost every day for hobby stuff and have used it from time to time professionally (among Java, python, typescript, c++).

    That being said amongst many of its users it has an almost cult like belief in its supremacy and imho attracts some bad people (not all). Because of how much it protects you, many bad developers find it and fall it love with it because it forces them to code correctly and then they can’t imagine that anybody else doesn’t need the guard rails they do. They also see that some of the smartest and best developments in software engineering happen in this space and want to attach themselves to it, and then use it as a bludgeon against others. Lots of very important software was written in languages that are not rust and they work just fine, were able to meet deadlines / be profitable Etc etc. but there is this attitude from many that if you aren’t picking Rust these days what are you even doing???

    Rust is great but it’s sometimes messy and not the right tool for the job. The whole “slower to develop but faster to correct” (which I’d say needs some real data to prove out, but for the sake of argument let’s say is true) is a trade off, not something that automatically makes it better. Sometimes due to circumstances way beyond your own control as a developer, you won’t know what the right answer is until halfway into development and there are languages that accommodate that scenario much better (imo). This is one of many of rust’s short comings. For a website, it’s just an unusual tool that even if equally useful from a language standpoint doesn’t have as much tooling and community support around it as other web languages. But I’d say it’s not equal even from a baseline level (again, my opinion. I’ve used rust plenty but I’ve never used it for web dev so I’m talking out my butt). Philosophically, does it make sense to over engineer a super powerful Ferrari of a website when a Toyota Camry will do? Especially when the Camry is tried and true and will likely let you be more agile.

    You can do anything in any language, but should you?

    • T0RB1T@beehaw.org
      link
      fedilink
      arrow-up
      7
      ·
      1 year ago

      That all makes a lot of sense. I really only ever got remotely competent with Python, and the one university course I did in c was rough. I passed it, but felt like I barely understood what I was doing the whole time.

      I can understand how ease of writing and general community mindshare can be the most important factors.

      • 1stTime4MeInMCU@mander.xyz
        link
        fedilink
        English
        arrow-up
        7
        ·
        edit-2
        1 year ago

        That’s too bad, I feel like mastering C is the key to having a super solid foundation for all things how computers work. (Not blaming you, most courses just blast through C without exploring the what and whys). There is something to be said for just getting people productive and for that Python is excellent and immediately engaging. Python is probably my best and favorite language, but I think from a wholistic understanding point of view its hard to beat a solid C foundation to build out from.

        • MasterBuilder@lemmy.one
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          Lower level languages are definitely helpful in learning how computers work. When I was in college, I was not taught C, but our algorithms course was in C. We were expected to learn it on our own.

          lisp and Prolog were used for AI - those we learned in class. Assembly was the ultimate “get intimate with the machine” language, and we wrote a simple compiler for VMS.

          All of this is meant to help us understand how to work with machines. It doesn’t mean that that’s how we should work with machines. Sometimes the higher level language is the better choice. Sometimes it is not. We are expected to make that decision based on the situation at hand.