• 0 Posts
  • 8 Comments
Joined 3 years ago
cake
Cake day: June 11th, 2023

help-circle
  • A few often overlooked ways to contribute:

    • artistic contributions: logos, banners
    • user interface design (I wish more UX folks participated in OSS, many projects could use the love)
    • improving documentation: as a new and/or novice user, you’re probably more sensitive to jargon that developers overlook and can help make documentation more useful to others like you
    • accessibility testing: testing software using accessibility settings like high contrast color schemes and screen readers. these use cases are often overlooked
    • project management: participate in the issues, see if the team wants help triaging or managing a discussion/chat platform

    Even if not code, some of these are quite specialized. Just be realistic about where you can add something useful.

    For all of these, it is critical that you first contact the maintainers and ask what they would find useful. Be mindful that it’s also work for the maintainers to manage your help. The only “wrong” way to participate in open source is to drop a bunch of work on someone unprompted.

    Generally, if a project already has a clear call for contributions or a contribution guide, that is a good indicator that the maintainers are willing to do a bit of community management to bring in help. I would only suggest investing energy in those projects if you have the choice.



  • Permissive licenses permit a broader range of use compared to “copyleft” licenses.

    “copyleft” here just being a cute way of being the opposite of copyright - instead of disallowing others from what they can do with “copyrighted” code, “copyleft” requires that they (upon request) share modifications to your code.

    Permissive takes away this requirement to share your modifications. “copyleft” is considered more free and open source (FOSS), permissive is more business friendly.



  • For anyone who’s curious, this is the state of discussing this feature: https://github.com/helix-editor/helix/discussions/8572

    I’m not an authority on the helix ethos, but I’ve contributed a bit and hung around long enough to have a good read on their stance on most topics. The project is still young and managing the growing pains of getting a lot of traction relatively early. I think the devs value keeping the maintenance footprint small to keep the project sustainable.

    The philosophy of helix’s design is to be a more convenient kakoune, not necessarily a vim. vim is much more widely known, so that analogy springs up more often, but this idea of using piping out to an external command for most operations comes from kakoune.

    For features that would introduce significant maintenance overhead, may jeopardize the performance of a more common workflow or where the design goals are still maturing, the team tends to push such suggestions toward being developed as plugins when that system is added. I get the impression that they see the value of this workflow, but would prefer to see it battle tested as a plugin first.


  • I’ve been there, but over the years I’ve gotten better at avoiding being in this situation.

    If you are implementing something for yourself, and merging it back upstream is just a bonus, then by all means jump straight to implementing.

    However, it’s emotionally draining to implement something and arrive at something you’re proud of only to have it ignored. So do that legwork upfront. File a feature request, open a discussion, join their dev chat - whatever it is, make sure what you want to do is valued and will be welcomed into the project before you start on it. They might even nudge you in a direction that you hadn’t considered before you started.

    Be a responsible dev and communicate before you do the work.



  • dgkf@lemmy.mltoMemes@lemmy.mlFirefox + uBlock Origin > Apps
    link
    fedilink
    English
    arrow-up
    5
    ·
    3 years ago

    The community-based project of passion to enhance lemmy is already here… it’s lemmy.

    This isn’t reddit. There isn’t a big black box and company around the service that is preventing the community from making it what they want it to be.

    Sure there can be flavors, but I’d guess if there’s the type of consensus around the usefulness as there is with RES, then why wait for a separate project to shoehorn features on top of lemmy when the folks behind lemmy seem quite receptive to contributions?