Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WeeChat's "no duplicate functionality scripts" policy should be lifted #16

Open
oakkitten opened this issue Dec 11, 2014 · 0 comments
Open
Labels
feature New feature request

Comments

@oakkitten
Copy link

Currently WeeChat's policy on new asks contributors to check "that no script (or pending script) does exactly same thing as your script" lest the script is rejected. I propose that this policy is lifted.

As I see it, the policy brings the following benefits

  • It's easier for user to choose a script that does what he wants as he's not baffled by the number of options

And has the following downsides

  • It, like, uh, simply doesn't work. Try /script search url

  • It prevernts developers from participating in script development. Let me explain this a bit. A while ago I noticed that the script colorize_lines.pl does not display mIRC colors, so I attemped to fix it. The script looked like this. It was almost 700 lines long, it lacked useful comments and (at least to my mind) contained a lot of weird code. I don't know what you might have done, but it's painful to me to correct such code, so rewrote the script from scratch. Now the script is less than 300 lines long, which makes it more than 3 times smaller if you don't count the code. And the script works fine with mIRC colors now. The script is now in the main repository.

    Now you may say that there's no problem with that. But colorize_lines.pl is used by a handful of people and doesn't exactly provide many options, so it was pretty much OK to release it without much testing. On the other hand, if I were to rewrite buffers.pl from scratch, I'd be facing the following problems:

    • this script is used by most weechat users, so it must be extensively tested before releasing
    • it provides a great number of options, which would be hard to reimplement
    • I cannot change options and other behavior in a way that would break current setup of the users of the script, even if it makes sense

    All this makes me discouraged from contributing to the existing script.

  • As a result of the previous point, scripts become series of patches with no major rewrites. I partly blame the policy for the following code in buffers.pl:

      for my $buffer (@buffers)
          {
          if (weechat::config_integer( $options{"sort"} ) eq 1)
              {

    Not only this code breaks style guidelines for perl, but it results in a call to config_integer for each iteration of the loop on the list, which happen on every hotlist change, while it is a rather expensive operation and could be called once per script launch.

  • It limits users' choice as well as contributors' competition

  • It forces users to use specific plugins if they want specific functionality

I suggest:

  • lifting the policy. Scripts can be rejected on project owner's discretion, but this policy just doesn't help
  • creating a setting such as "show dev scripts" which would allow installing of developing scripts from /script repository, promoting testing of new scripts

P.S. Some of the scripts are really broken;
P.P.S. I don't believe this will result in a huge flood of amateur scripts;
P.P.P.S. If at some point there are a lot of scripts that do te same thing, we can just remove the worst of them or the abandoned ones from the repository

@flashcode flashcode added the feature New feature request label Jan 25, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature request
Projects
None yet
Development

No branches or pull requests

2 participants