Loading ...
Sorry, an error occurred while loading the content.
 

Re: vim sf page ratings and feedback feature

Expand Messages
  • Bram Moolenaar
    ... The problem with feedback is that spammers will misuse it. We have had this problem with Vim tips before they were moved to the wikimedia site. If we can
    Message 1 of 20 , Feb 9, 2010
      Marc Weber wrote:

      > Hi Bram & community,
      >
      > There are two things on the Vim sf page which bugged me for years:
      >
      > a)
      > There is no way for users adding comments.
      >
      > So as plugin author you just get feedback like a rating -2/2 but you
      > have no clue why. That's very disappointing.
      > This happened to me recently.
      > http://www.vim.org/scripts/script.php?script_id=2934
      > I think this plugin is great because you don't have to remember dozens
      > of mappings.
      >
      > To keep open source projects active you need positive feedback loops.
      > This doesn't happen for Vim plugins.
      >
      > So consider one case: You have uploaded a bug by accident. One users
      > downloads your plugin. It doesn't work. So he rates the plugin with
      > (-1).
      >
      > You can fix the bug. You rating is still -1. The only thing you can do
      > about it is polluting the page by adding a new plugin-name which is bad.

      The problem with feedback is that spammers will misuse it. We have had
      this problem with Vim tips before they were moved to the wikimedia site.

      If we can put the comments also on the wikimedia site, with a link to
      it, perhaps that would work.

      > b)
      > users can't add comments. So if there is a newer plugin or if
      > something didn't work or if users have additional comments whatsoever
      > they can't put them on the site. The result is that the site isn't as
      > valuable as it could be. Eg have a look php.net. If there is a bug
      > everyone can upload a comment posting his workaround. It's ugly but it
      > works pretty well.
      >
      > Indeed it can be much simpler. Adding one link to a discussion site on
      > the Vim wiki eg http://$VIMWIK/pulgin_plguin_nr would be enough.
      > Zero effort but much value.

      You can already add links, but a generic mechanism would indeed be
      better.

      There, I added a link in the header. Let me know if this will work.

      John Beckett can perhaps set up a template for a scripts wiki page.

      > c) (less important)
      > Plugin information can't be exported. This I and the author of Vimana
      > we both implemented hacks to get a list of plugins to support
      > installing plugins in an easier way.
      >
      > So I'd like to add an interface which returns a big json dict (which
      > can be read by Vim!) telling about all plugins and their latest
      > versions. This will safe some traffic and a lot of CPU power..

      Since there is no specified format, I don't know of a reliable way to do
      this.

      I don't think there is a way to get a list of uploaded files by date.
      Perhaps that's all you need.

      > I know both: PHP and MySQL. I can do all changes. There is one thing I'm
      > unsure about. The Vim database contains information about who donated
      > how much. This is sensible data. I'm not sure whether I should know
      > about those records.
      >
      > So what shall I do to get these features implemented? Ask community on
      > the mailinglist how they think about it?
      >
      > Those changes don't cause much work. But they will generate much value
      > to everyone.

      I'm careful about giving more people access to the site directly. If
      you say what page you would want to change I can send you the php code
      and you can send me a diff.

      --
      hundred-and-one symptoms of being an internet addict:
      211. Your husband leaves you...taking the computer with him and you
      call him crying, and beg him to bring the computer back.

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ download, build and distribute -- http://www.A-A-P.org ///
      \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

      --
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
    • Tux
      ... BTW, did you switch SF.net s new no export to North Korea switch? -- You received this message from the vim_dev maillist. For more information, visit
      Message 2 of 20 , Feb 9, 2010
        Bram Moolenaar schrob am 09.02.2010 21:20:
        > I'm careful about giving more people access to the site directly.
        >

        BTW, did you switch SF.net's new "no export to North Korea" switch?

        --
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
      • John Beckett
        ... Yes, we could request a namespace specifically for discussion of vim.org scripts. However, while the problem with vim.org/scripts is real, I do not want a
        Message 3 of 20 , Feb 9, 2010
          Ben Fritz wrote:
          > For a while now, we've been resisting having a wiki page for
          > every plugin out there, as such information could easly become
          > overwhelming or get out of date. We want searches on the wiki
          > to show mostly tips about how to use Vim, how to write
          > scripts, etc. We didn't want it to become a place to search
          > for plugins.
          >
          > Perhaps it would be possible, if we create a new namespace for
          > the plugin pages (I think this is possible). Searches would by
          > default not include these pages, but a user could specify that
          > they *wanted* to search the plugin namespace if desired.

          Yes, we could request a namespace specifically for discussion of
          vim.org scripts. However, while the problem with vim.org/scripts
          is real, I do not want a bunch of extra pages dumped on the wiki
          because such pages:
          - overwhelm people looking for basic information
          - become obsolete as once-enthusiastic authors move on
          - have to be maintained by me and Ben Fritz

          If we could start again, vim.org/scripts might be managed
          differently, but I think there is too much history now for any
          realistic collaboration between the scripts site and a wiki
          because we cannot force people to update the information on two
          different sites.

          If it were possible to put the plugins into a reasonably small
          number of categories, then it would be reasonable to have one
          wiki page per category of script. For example, one wiki page
          would list all non-obsolete plugins relating to searching, with
          brief notes on status and usage, and a link to the
          vim.org/scripts page for installation and usage notes.

          I made a page on the wiki to hold various scripts that had
          previously been described in separate tips. I think the format
          is useful to allow readers to quickly scan for interesting
          scripts:
          http://vim.wikia.com/wiki/Vim_scripts

          There was a suggestion that a wiki page would allow users to
          write meaningful comments with useful feedback. Unfortunately,
          I think useful comments would be very rare because people are
          overwhelmed with choice on the Internet, and Vim is now just
          another tool, and the hard-core Vim users are just using Vim,
          having got over the initial wave of evangelism that creates an
          interactive fan base.

          John

          --
          You received this message from the "vim_dev" maillist.
          For more information, visit http://www.vim.org/maillist.php
        • Ingo Karkat
          ... I agree that there should be very few committers to the site; however, in my opinion, freely sharing the (PHP) source code of the site might have
          Message 4 of 20 , Feb 9, 2010
            On 09-Feb-2010 21:20, Bram Moolenaar wrote:
            > I'm careful about giving more people access to the site directly. If
            > you say what page you would want to change I can send you the php code
            > and you can send me a diff.

            I agree that there should be very few committers to the site; however, in my
            opinion, freely sharing the (PHP) source code of the site might have encouraged
            more people to send you a patch in order to improve the site's functionality.
            As it is, there are these occasional discussions about the site's deficiencies,
            but nobody is able to step up and implement an alternative, because the source
            code is relatively closed.

            So, I would propose putting the vim.org's source code (not the actual user
            database and scripts!) into a (Mercurial?) repository (separate from Vim's
            source code).

            -- regards, ingo

            --
            You received this message from the "vim_dev" maillist.
            For more information, visit http://www.vim.org/maillist.php
          • Bram Moolenaar
            ... This would also make the site vunerable for hackers. I don t know enough PHP to locate possible holes and opening it up won t fix that. I rather not do
            Message 5 of 20 , Feb 10, 2010
              Ingo Karkat wrote:

              > On 09-Feb-2010 21:20, Bram Moolenaar wrote:
              > > I'm careful about giving more people access to the site directly. If
              > > you say what page you would want to change I can send you the php code
              > > and you can send me a diff.
              >
              > I agree that there should be very few committers to the site; however,
              > in my opinion, freely sharing the (PHP) source code of the site might
              > have encouraged more people to send you a patch in order to improve
              > the site's functionality. As it is, there are these occasional
              > discussions about the site's deficiencies, but nobody is able to step
              > up and implement an alternative, because the source
              > code is relatively closed.
              >
              > So, I would propose putting the vim.org's source code (not the actual
              > user database and scripts!) into a (Mercurial?) repository (separate
              > from Vim's source code).

              This would also make the site vunerable for hackers. I don't know
              enough PHP to locate possible holes and opening it up won't fix that.
              I rather not do this. Having only a few maintainers looking at the code
              is better.

              --
              hundred-and-one symptoms of being an internet addict:
              212. Your Internet group window has more icons than your Accessories window.

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              \\\ download, build and distribute -- http://www.A-A-P.org ///
              \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

              --
              You received this message from the "vim_dev" maillist.
              For more information, visit http://www.vim.org/maillist.php
            • Tom Sorensen
              ... Really? Security through obscurity? If the site is vulnerable, then I don t believe that having the source hidden is going to significantly deter a hacker.
              Message 6 of 20 , Feb 10, 2010
                On Wed, Feb 10, 2010 at 9:47 AM, Bram Moolenaar <Bram@...> wrote:
                > This would also make the site vunerable for hackers.  I don't know
                > enough PHP to locate possible holes and opening it up won't fix that.
                > I rather not do this.  Having only a few maintainers looking at the code
                > is better.

                Really? Security through obscurity?

                If the site is vulnerable, then I don't believe that having the source
                hidden is going to significantly deter a hacker. It will certainly
                impede any attempts to fix it though.

                I love vim and greatly appreciate all of the work you've put into it
                and the community over the past two decades. But the website really
                could use some improvement. The wiki has done a lot to fill some of
                the need (a need we see regularly on the #vim IRC channel), but having
                tighter integration with the main site would be far better, without
                overwhelming the wiki. That's not going to happen unless people like
                Marc can easily and readily provide help where they can.

                Tom

                --
                You received this message from the "vim_dev" maillist.
                For more information, visit http://www.vim.org/maillist.php
              • Marc Weber
                We should start a wiki page containing a website wish list. We can put up a summary of changes there. Bram: I m totally fine with sending you diffs. If nobody
                Message 7 of 20 , Feb 10, 2010
                  We should start a wiki page containing a website wish list.
                  We can put up a summary of changes there.

                  Bram: I'm totally fine with sending you diffs.

                  If nobody else does I'll create this wiki page within 24h

                  Marc Weber

                  --
                  You received this message from the "vim_dev" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                • Marc Weber
                  Done. If you have further suggestions reply to this thread or add them to this wiki page yourself.
                  Message 8 of 20 , Feb 10, 2010
                    Done. If you have further suggestions reply to this thread or add them
                    to this wiki page yourself.
                    http://vim.wikia.com/index.php?title=Vim_Homepage_Wishlist&action=edit

                    I also suggested removing the negative rating feature. Maybe its
                    misused. If people don't like a plugin they should add comments telling
                    why.

                    Also have a look at a new idea e) It may or it may not take off.
                    I think there are that many people using vim that this could actually
                    make sense..

                    e) I'd like to see Vim making more progress. Thanks to Bram for having
                    added completion features. However there is more which could be done.
                    What's the problem? Vim is complex. Many configuration options, many
                    guis. So it's hard to test. You need some time getting started. Most
                    people just want to get done their job. So it's hard to get started in
                    Vim development. So what about adding a page to the homepage where
                    everyone can add a feature request and say he'd pay $ x for it. Someone
                    else might join and say he'd pay $ y for it. Then a third person steps
                    up and says: Hey. I'd take the money and implement it (maybe a fraction
                    can be given to Uganda?). Than a Vim developer can have an (probably
                    small ?) income and many people can benefit. Such a feature wish list
                    could look like:

                    feature | description | sum of $ which people are willing
                    | | to spend on developing a feature
                    -------------------------------------------------------------------------------------------------
                    async communication| find a way to talk to external apps. | $100 (3 people)
                    | This will make implementing debuggers |
                    | and the like feasable |
                    -------------------------------------------------------------------------------------------------
                    on the fly | make scripting languages provide |
                    type checking | the error list |
                    -------------------------------------------------------------------------------------------------
                    on :e! don't loose | |
                    history | |

                    Does a simple buildfarm exists which builds Vim in various configuration
                    options doing some sanity checks?

                    Marc Weber

                    --
                    You received this message from the "vim_dev" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                  • Ingo Karkat
                    ... PHP is very common; there are many Vim users with a lot of PHP knowledge out there. The vim.org site isn t very complex; I guess one or two capable
                    Message 9 of 20 , Feb 10, 2010
                      On 10-Feb-2010 15:47, Bram Moolenaar wrote:
                      > Ingo Karkat wrote:
                      >> So, I would propose putting the vim.org's source code (not the actual
                      >> user database and scripts!) into a (Mercurial?) repository (separate
                      >> from Vim's source code).
                      >
                      > This would also make the site vunerable for hackers. I don't know
                      > enough PHP to locate possible holes and opening it up won't fix that.
                      > I rather not do this. Having only a few maintainers looking at the code
                      > is better.

                      PHP is very common; there are many Vim users with a lot of PHP knowledge out
                      there. The vim.org site isn't very complex; I guess one or two capable
                      contributors would be able to quickly review and fix any security issues. I
                      certainly would (but I'm afraid my PHP isn't any better than yours), just out of
                      gratitude for Vim and the great community.

                      Leaving aside the whole "security by obscurity" topic, I'd venture that the
                      tech-savvy vim.org community isn't a prime target for hackers, so IMO it's worth
                      a risk. As you can see from the replies to this thread, the current site is
                      minimal and okay, but there are many ideas for improvements out there. In the
                      past years, many open source projects have really lifted the bar for community
                      sites...

                      -- regards, ingo

                      --
                      You received this message from the "vim_dev" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                    • Marc Weber
                      ... I don t think it s a problem. Bram said he will forward sources to interested people. I just said he won t forward it to everyone. I don t think this is
                      Message 10 of 20 , Feb 11, 2010
                        Excerpts from Ingo Karkat's message of Thu Feb 11 07:32:53 +0100 2010:
                        > On 10-Feb-2010 15:47, Bram Moolenaar wrote:
                        > > Ingo Karkat wrote:
                        > >> So, I would propose putting the vim.org's source code (not the actual
                        > >> user database and scripts!) into a (Mercurial?) repository (separate
                        > >> from Vim's source code).
                        > >
                        > > This would also make the site vunerable for hackers. I don't know
                        > > enough PHP to locate possible holes and opening it up won't fix that.
                        > > I rather not do this. Having only a few maintainers looking at the code
                        > > is better.
                        >
                        > PHP is very common; there are many Vim users with a lot of PHP knowledge out
                        > there. The vim.org site isn't very complex; I guess one or two capable
                        > contributors would be able to quickly review and fix any security issues. I
                        > certainly would (but I'm afraid my PHP isn't any better than yours), just out of
                        > gratitude for Vim and the great community.
                        >
                        > Leaving aside the whole "security by obscurity" topic, I'd venture that the
                        > tech-savvy vim.org community isn't a prime target for hackers, so IMO it's worth
                        > a risk. As you can see from the replies to this thread, the current site is
                        > minimal and okay, but there are many ideas for improvements out there. In the
                        > past years, many open source projects have really lifted the bar for community
                        > sites...

                        I don't think it's a problem. Bram said he will forward sources to
                        interested people. I just said he won't forward it to everyone. I don't
                        think this is limiting us. We have to know how the "new" (?) site should
                        look like. So let's discuss new features or changes rather than the how
                        to do it. Bram replied and he's listening. So I'm sure we'll find a way
                        to achieve the goals. We have to define those.

                        Marc Weber

                        --
                        You received this message from the "vim_dev" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                      • Ben Schmidt
                        ... My PHP is pretty good; MySQL also, though old-fashioned. If I can be of assistance looking over code, or helping with development for a better site, I d be
                        Message 11 of 20 , Feb 11, 2010
                          On 12/02/10 3:34 AM, Marc Weber wrote:
                          > Excerpts from Ingo Karkat's message of Thu Feb 11 07:32:53 +0100 2010:
                          >> On 10-Feb-2010 15:47, Bram Moolenaar wrote:
                          >>> Ingo Karkat wrote:
                          >>>> So, I would propose putting the vim.org's source code (not the actual
                          >>>> user database and scripts!) into a (Mercurial?) repository (separate
                          >>>> from Vim's source code).
                          >>>
                          >>> This would also make the site vunerable for hackers. I don't know
                          >>> enough PHP to locate possible holes and opening it up won't fix that.
                          >>> I rather not do this. Having only a few maintainers looking at the code
                          >>> is better.
                          >>
                          >> PHP is very common; there are many Vim users with a lot of PHP
                          >> knowledge out there. The vim.org site isn't very complex; I guess one
                          >> or two capable contributors would be able to quickly review and fix
                          >> any security issues. I certainly would (but I'm afraid my PHP isn't
                          >> any better than yours), just out of gratitude for Vim and the great
                          >> community.

                          My PHP is pretty good; MySQL also, though old-fashioned. If I can be of
                          assistance looking over code, or helping with development for a better
                          site, I'd be more than happy to.

                          I agree with Bram and Marc that having a few interested people looking
                          at the site code rather than making it public is fine. We're a pretty
                          tech-savvy community, but that doesn't mean everybody has time to devote
                          to fixing security holes, particularly not with the sort of notice you
                          get with a hacker attack!

                          Ben.




                          --
                          You received this message from the "vim_dev" maillist.
                          For more information, visit http://www.vim.org/maillist.php
                        • Ben Fritz
                          ... John s been a busy bee and got a new namespace on the wiki for script comments, a policy page for it, and a nifty template for each script page providing a
                          Message 12 of 20 , Feb 13, 2010
                            On Feb 10, 12:44 am, "John Beckett" <johnb.beck...@...> wrote:
                            > Yes, we could request a namespace specifically for discussion of
                            > vim.org scripts. However, while the problem with vim.org/scripts
                            > is real, I do not want a bunch of extra pages dumped on the wiki
                            > because such pages:
                            > - overwhelm people looking for basic information
                            > - become obsolete as once-enthusiastic authors move on
                            > - have to be maintained by me and Ben Fritz
                            >

                            John's been a busy bee and got a new namespace on the wiki for script
                            comments, a policy page for it, and a nifty template for each script
                            page providing a disclaimer and brief instructions, along with the
                            script name and a link back to vim.org.

                            Check it out:

                            http://vim.wikia.com/wiki/Vim_Tips_Wiki:Script_comment_guidelines
                            http://vim.wikia.com/wiki/Script:1234

                            Bram, I'm not sure if John emailed you privately, but if you'd change
                            the link to the wiki on vim.org pages from Script-1234 to Script:1234,
                            I think that's all that you need change.

                            Comments are, of course, welcome.

                            --
                            You received this message from the "vim_dev" maillist.
                            For more information, visit http://www.vim.org/maillist.php
                          • Marc Weber
                            ... Looks great. However I d move the Wiki link near the rating. And I d still remove negative ratings. Scripts which are awesome will have a high rating
                            Message 13 of 20 , Feb 13, 2010
                              Excerpts from Ben Fritz's message of Sat Feb 13 19:16:42 +0100 2010:
                              >
                              > On Feb 10, 12:44 am, "John Beckett" <johnb.beck...@...> wrote:
                              > > Yes, we could request a namespace specifically for discussion of
                              > > vim.org scripts. However, while the problem with vim.org/scripts
                              > > is real, I do not want a bunch of extra pages dumped on the wiki
                              > > because such pages:
                              > > - overwhelm people looking for basic information
                              > > - become obsolete as once-enthusiastic authors move on
                              > > - have to be maintained by me and Ben Fritz
                              > >
                              >
                              > John's been a busy bee and got a new namespace on the wiki for script
                              > comments, a policy page for it, and a nifty template for each script
                              > page providing a disclaimer and brief instructions, along with the
                              > script name and a link back to vim.org.
                              >
                              > Check it out:
                              >
                              > http://vim.wikia.com/wiki/Vim_Tips_Wiki:Script_comment_guidelines
                              > http://vim.wikia.com/wiki/Script:1234
                              >
                              > Bram, I'm not sure if John emailed you privately, but if you'd change
                              > the link to the wiki on vim.org pages from Script-1234 to Script:1234,
                              > I think that's all that you need change.

                              Looks great. However I'd move the Wiki link near the rating. And I'd
                              still remove negative ratings. Scripts which are awesome will have a
                              high rating anyway and you're interested in them.

                              Is there a way to add the wiki frame to the vim sf script page?
                              If some people don't like it we can add an option to hide it (based on
                              cookies).

                              Marc Weber

                              --
                              You received this message from the "vim_dev" maillist.
                              For more information, visit http://www.vim.org/maillist.php
                            • Tony Mechelynck
                              On 11/02/10 01:23, Marc Weber wrote: [...] ... It s easy to construct one, but only on Unix-like systems, including Unix-like Cygwin and (IIUC) Mac OS X. Not
                              Message 14 of 20 , Apr 4, 2010
                                On 11/02/10 01:23, Marc Weber wrote:
                                [...]
                                > Does a simple buildfarm exists which builds Vim in various configuration
                                > options doing some sanity checks?
                                >
                                > Marc Weber
                                >

                                It's easy to construct one, but only on Unix-like systems, including
                                Unix-like Cygwin and (IIUC) Mac OS X. Not on native-Windows AFAIK,
                                because the configure script doesn't run on that platform. I guess you
                                (Marc) know the following but I'm spelling it out for anyone interested:

                                0) Get the source.
                                1) Make as many "shadow" subdirectories of src/ as you want different
                                configurations, using "make shadow" with src/Makefile; after each pass,
                                rename src/shadow (or comment away the Makefile line "SHADOWDIR =
                                shadow" and define SHADOWDIR differently yourself for each run of "make
                                shadow").
                                2) Construct shell include scripts (let's call them
                                src/$SHADOWDIR/config.sh) similar to the one near the top of my howto
                                page http://users/.skynet.be/antoine.mechelynck/vim/compunix.htm , one
                                per configuration with the desired settings.
                                -- For some particularly "unusual" configurations, you may have to break
                                the softlink for feature.h and comment or uncomment some of its lines
                                differently in different shadowdirs.
                                3) In each shadowdir:
                                source config.sh
                                make && make test

                                Notes:

                                * Run the above in a different shell for each shadowdir to avoid stray
                                environment variables carrying over from one run to the next. You may
                                run them in parallel if you want (and if your machine has the resources
                                to make it useful).

                                * config.sh must be sourced, not run, because its purpose is to modify
                                the environment: it must NOT be run in a subshell.

                                * "make" runs configure implicitly if auto/config.cache doesn't exist;
                                if you changed the config.sh or the installed software, use "make
                                reconfig" instead (or precede "make" by rm -vf auto/config.cache or by
                                make distclean) to force a configure pass followed by a full compile.

                                * "make test" is supposed to run a number of post-compile sanity checks
                                on the newly produced executable. I haven't tried it yet. Pre-compile
                                sanity checks (on your software environment and configuration settings)
                                are done by configure.


                                Best regards,
                                Tony.
                                --
                                TALL KNIGHT: We shall say Ni! again to you if you do not appease us.
                                ARTHUR: All right! What do you want?
                                TALL KNIGHT: We want ... a shrubbery!
                                "Monty Python and the Holy Grail" PYTHON (MONTY)
                                PICTURES LTD

                                --
                                You received this message from the "vim_dev" maillist.
                                Do not top-post! Type your reply below the text you are replying to.
                                For more information, visit http://www.vim.org/maillist.php

                                To unsubscribe, reply using "remove me" as the subject.
                              Your message has been successfully submitted and would be delivered to recipients shortly.