Hi there, in the upcoming kbin releases, I will be describing the changes along with author tags, but for now, you can check out what’s happening here: https://codeberg.org/Kbin/kbin-core/activity, as well as my personal feed: https://ernest.dev

Today, two test instances will be created where we will be looking for bugs for some time, and then the changes will be rolled out to kbin.social and hopefully other instances as well :)

I want to accept as many pull requests as possible, currently, there are still 50 open ones. I’m also following your posts and adding new things to the to-do list.

Have a nice day!

  • Mnmalst@kbin.social
    link
    fedilink
    arrow-up
    100
    ·
    1 year ago

    Appreciate all your work and I am enjoying kbin but please make sure you are not burning yourself out. I have seen it too many times, especially in open source projects that become super popular all of a sudden. Take care of your mental health and work at a pace that you still enjoy. You don’t ow us anything.

    Have a great Sunday!

    • AnonymousLlama@kbin.social
      link
      fedilink
      arrow-up
      42
      ·
      1 year ago

      There’s quite a few of us now helping out with tickets. Great to see lots of people coming together to make the site better. Good to get lots of bugs squashed :)

      • Mnmalst@kbin.social
        link
        fedilink
        arrow-up
        21
        ·
        1 year ago

        Love it! But that is or can be part of the “problem”. Suddenly it’s not “I am working on the software I like” anymore but “managing merge requests all day”. Not saying that’s what’s happening here tho. It can be a problem.

        • ernest@kbin.socialOP
          link
          fedilink
          arrow-up
          10
          ·
          1 year ago

          @Mnmalst Yeah, I am well aware of what you’re talking about, and I am trying to maintain a balance. I knew that it could look like this at a certain stage, but I didn’t expect it to happen so quickly ;) I assumed I would have a bit more time to prepare and acquire knowledge. Now I have to improvise. I make mistakes, but I try to fix them and always keep an eye on the big picture. That’s all I can do. Working with pull requests is great, I enjoy learning new things from others, and it’s also fun to discover bugs together. At least for now. ;-) But I always emphasize that my priorities are my milestones, which keep me afloat, so I care about organizing our collaboration as quickly and effectively as possible. However, we also need to get to know each other a little better.

          • Mnmalst@kbin.social
            link
            fedilink
            arrow-up
            2
            ·
            1 year ago

            Sounds like you have a working structure for now. :) I hope it all stays like this for you. I am exited about the future! Wish you the best.

        • CoderKat@kbin.social
          link
          fedilink
          arrow-up
          9
          ·
          1 year ago

          I think it’s important to not have a single person having to deal with those. But admittedly it’s hard to get to that point. I’ve only significantly done established, commercial software dev, where you can just trust your coworkers. Random people on the internet are harder to trust. Anyone can play nice for a couple of days for a chance to slip in something malicious.

          The project is not only rather new (so any contributors are gonna be new), but it’s also hosted on an unfamiliar site (which is to say, it’s not GitHub), so most people don’t have an account with history either.

        • Gone Quill
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          If possible what I’ve seen help very much is to have a second person join on as being the “ticket review guy.” That person will act as a community manager and really won’t do that much coding. Usually they’ll have a technical background and will understand the code they’re reading in pull requests, but for the most part they’re there to allow the primary code writer to focus on writing big features and executing core vision while the community at large contributes fixes, tweaks, and features that hadn’t been baked into the core vision