I’m working on open source projects :)

🔗 Links:

GitHub Reddit

🍪 Get me a cookie:

Go to Ko-fi GitHub Sponsor
  • 84 Posts
  • 117 Comments
Joined 1 year ago
cake
Cake day: June 18th, 2023

help-circle


  • Thank you for putting all this together!

    Potential conflict of interest: I help with !instance_assistant@lemmy.ca

    Having a separate list for extensions would work nicely, although I think it fits to have the extensions listed here. There are few actual browser extensions for Lemmy/Kbin/Mastodon. There are a lot of scripts, and we were working on incorporating the better scripts into the extension for the same reasons you mentioned above. Scripts are harder to manage and review

    My thoughts on the questions.

    1. “last stable version” sounds like a good way to sort it, for readers. It might become cumbersome for you to manage unless you can automate it somehow.
    2. I’m leaning towards flagging or removing out of date apps because of potential security issues. Could you contact devs after a few months to ask if it is being maintained?
    3. A big list of every app would be interesting for data. It isn’t helpful for users, so I agree with keeping them off
    4. I have a donation link. I don’t think it should be included in guides or lists either
    5. I like the formatting, as a reader. Consider if it becomes too cumbersome for you and your team to manage. I’d rather have a list that stays up to date and doesn’t cause headaches for the maintainer









  • I was chatting with a friend, and she mentioned how she tries to at least set up a README, which includes her vision for the project and her plan for the implementation, design, and goals.

    Best case scenario is that the planning helps her complete the project herself. Worst case scenario, someone else can pick up where she left off and use her considerations for the project.

    I’m thinking of doing that for future projects too












  • Look, honestly: if you want Facebook ot Twitter, go back to them.

    This post was to talk about the merits/drawbacks of a potential change, and the constructive comments on the post have been helpful for that. Some of the other ‘solutions’ that have been posted here feel even more antithetical to the idea of decentralization (ex. redirecting upvotes, having communities follow other communities) so I was looking for a compromise that would address some of the annoyances without making the site another centralized platform. The intent was to allow users to choose how they want to link cross posts together, rather than having the community (or an app/frontend) make the decision for them. We’ve also been seeing users naturally gravitate to a few instances/communities, so I was looking for ways to redirect some of that traffic back to lesser known spaces.

    Regardless, I appreciate the comment. Reading the perspectives on this post helped me see how locking the post completely would cause more issues and annoyances than it would help with. A simple “we are discussing X over on this post, feel free to join” seems like the better compromise.



  • Everyone who’s subscribed to the same communities will see all of each others’ comments.

    This still relies on everyone using the same app/front-end.

    I guess I’m thinking about how it would be helpful in more general cases. If someone has an issue with a FOSS app, and they ask about it in two small communities, it would be much better to have the troubleshooting discussion in one place rather than have both communities missing part of the context.

    Ultimately in your example, the user can still make both posts, this doesn’t change that. It just directs the comments to one post’s comment section rather than having it spread out.

    Still it’s good to think about cases where OP tries to abuse the system. Would a good middle ground just be the first implementation then? For OP to link to the post that they want to be the main discussion thread, but people are free to ignore that if they want.