a month later

matteocontrini I can create a PR if it's welcome.

In open source that would be more than welcome than maintaining a fork 😉 Especially because you making a PR is less work than the maintainer making changes to that file again.

      luceos I was asking because Clark in the past said that he would "generally advise against it", because it takes less for him to make the changes himself, I think. 🙂

      Anyway I'll go ahead, since PRs are free 😆 . I don't think it even requires testing, it's just a matter of tagging a new version.

        Yeah to recap our previous discussions that people on the forum might not have seen I'm not a fan of PRs other than typo fixes on my repositories (particularly the low maintenance ones) because they take me more time to properly clone, rebase if necessary, merge and review versus just making the change on master and immediately testing and releasing.

        Also just from a licensing standpoint, I prefer to author small commits myself instead of having new authors added to the git history. I do usually consider commits to my repositories as signed-off since the LICENSE file isn't updated but since there's no proper contribution agreement in place it's just simpler if I make those commits myself.

        Unless I am 100% certain the change won't have any side effect, I don't merge PRs without testing the extension. Testing and releasing is often what takes the most time on "small" fixes.

        This particular extension is extremely simple, so I'll try to make the change and tag a new release when I find some time. But I still want to clone it locally and make sure that everything is good myself. That's not just testing the extension works, it's also verifying the README is up to date and matches with my current template, that the LICENSE year is correct and that the javascript dependencies are up to date (that particular one doesn't apply here luckily since there's no javascript).

        2 years later

        Hello @clarkwinkelmann ,
        I once used your extension to solve this problem, but later I no longer needed it and uninstalled it (performed a purge before uninstalling). However, I found two values, discussion.editOwnPostForever and discussion.editOwnFirstPostForever, in the group_permission table that seem to be related to this extension. Are these two values still necessary? I'm not sure if it's safe to delete them directly.

          HeapsortYi yes it looks like those entries came from my extension and yes it would be safe to delete them.

          Keeping them shouldn't have any impact though. Those entries are only queried when an extension makes a call to the permission system with that specific name.