You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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:
formy$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
The text was updated successfully, but these errors were encountered:
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
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 rewritebuffers.pl
from scratch, I'd be facing the following problems: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
: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:
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
The text was updated successfully, but these errors were encountered: