On 2016-08-20 12:20, Jonathan McDowell wrote:
On Thu, Aug 18, 2016 at 08:55:48PM -0400, Filipus Klutiero wrote:
On 2016-08-14 16:25, Jonathan McDowell wrote:
Based on experience managing a number of wikis I think the workload
involved in helping people who want to contribute at present but
can't deal with ikiwiki is significantly lower than dealing with an
open (or even approval based) wiki or CMS.
I am not sure what you meant exactly by "deal", but recruitment of
contributors unable to *use* the current system is not the main
benefit I see. I was rather seeing a switch as a way to make
contributing more appealing.
Are you saying that you think people don't contribute because of the
overhead of submitting changes to the ikiwiki+git system, rather than
because they don't understand it?
Not exactly. I am saying that people would contribute more if:
1. The knowledge required to contribute was less costly to learn, or already
more widespread
2. There was no need to setup a rare system to validate a suggested solution
before submitting it.
3. It could be determined before proposing a change whether the same
proposition is already waiting processing.
4. It could be determined before proposing a change whether the same
proposition was already made and rejected.
5. Proposing a change was less costly, indeed.
6. It was possible to receive a confirmation that a change was queued when
proposing it.
(As I initially conceded, some of these can be achieved without adopting a CMS
or wiki)
As for the workload involved in dealing with wikis or CMS-s, were you
referring to content administration?
I'm referring to the unfortunate way in which spammers attach themselves
to any uncurated website that allows anonymous or easy registration
submissions.
OK. As I wrote, this request does not demand to allow anonymous modifications.
In fact, I would be concerned with allowing anonymous modifications, except
*perhaps* on specific pages. As for easy registration submissions, the
registration process could be the same as the process to become a SPI member if
we are willing to restrict submissions to SPI members, which I consider most
reasonable (it would already be a lot more open). While allowing this might
cause more fraudulent registrations as SPI members, it would largely reduce the
proportion of legitimate changes going to webmas...@spi-inc.org.
I think we'd spend a lot more time cleaning things up if
the system in use allowed such things, and that the website as a whole
would suffer as a result - the negative impact of having to clean such
things up would seriously outweigh the drive-by improvements from people
who don't want to email webmaster@ or submit a Markdown patch.
Switching to a CMS or wiki does not necessarily mean we need to spend time removing spam.
Modifications from non-members do not need to be allowed, and if they are, they can be
set to not display by default ("pending changes").
And the advantages of solving this are not limited to "the drive-by improvements
from people who don't want to email webmaster@ or submit a Markdown patch", as you
describe them. Solving this optimizes the work of those people who are willing to
contribute in the current situation, and there are also indirect benefits. Every time we
ease contributing, we increase the number of contributions from newcomers who will build
a trust in the project's capacity to treat their contributions properly. And contributing
is also how contributors learn more about a project, which is necessary for them to
become better contributors.
2 of the 3 social production projects I contributed the most to are extremely
open and easy to contribute to. In both cases, I made my first contribution
from my browser.
The first one is Tiki, where I started doing issue triaging in an ITS which
could be manipulated from browser. When I was recruited as a developer, I said
I had no time to contribute more. Yet, a few months later I was learning the
implementation languages (PHP, Smarty and SQL, which are also relatively easy)
and becoming a top contributor, until I realized I had become addicted to that
project and resigned.
The other project is Wikipedia, which I did not want to contribute to for
several months, before I was so tempted to intervene that I created an account
and made a first comment. And of course, I then learned the syntax, the
policies, perfected my English, and made thousands of edits.
In both of these cases, I had no intention to become a regular contributor when
I made my first contribution. At that time, I would have bet that I would not
contribute thousands of hours to these projects. Perhaps it would have been
more efficient for me to learn the skills necessary to contribute to different
projects which were less open and easy to contribute to, but that is not what
happened, because I was never looking for a project to get involved in, I just
noticed issues in these projects and found I could easily help solving them. It
is just too easy to get involved when... it is easy to start contributing.
That being said, I have stopped contributing to these 2 projects because their
openness is extreme and hurts their products and the productivity of
contributors. One could say the same thing which got me involved got me to
leave later, but I think we can distinguish because the technical barriers to
entry and openness. I am asking here to lower the technical barriers to entry,
not to increase openness. I tend to think that more openness would also help,
but that is not necessary to solve this issue.
Regarding your "drive-by" qualification, you might be right if you are implying
that a potential contributor's knowledge of markup languages is correlated to his level
of relevant experience, but I would counter that the level of relevant experience is
inversely proportional to the probability of that potential contributor prioritizing work
for SPI among all the options he chooses to spend his time on.
--
Filipus Klutiero
http://www.philippecloutier.com
_______________________________________________
Spi-general mailing list
Spi-general@lists.spi-inc.org
http://lists.spi-inc.org/listinfo/spi-general
