<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2016-08-20 12:20, Jonathan McDowell
wrote:<br>
</div>
<blockquote cite="mid:20160820162046.GH19933@earth.li" type="cite">
<pre wrap="">On Thu, Aug 18, 2016 at 08:55:48PM -0400, Filipus Klutiero wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 2016-08-14 16:25, Jonathan McDowell wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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?</pre>
</blockquote>
<br>
Not exactly. I am saying that people would contribute more if:<br>
<ol>
<li>The knowledge required to contribute was less costly to learn,
or already more widespread</li>
<li>There was no need to setup a rare system to validate a
suggested solution before submitting it.</li>
<li>It could be determined before proposing a change whether the
same proposition is already waiting processing.</li>
<li>It could be determined before proposing a change whether the
same proposition was already made and rejected.</li>
<li>Proposing a change was less costly, indeed.</li>
<li>It was possible to receive a confirmation that a change was
queued when proposing it.</li>
</ol>
(As I initially conceded, some of these can be achieved without
adopting a CMS or wiki)<br>
<br>
<blockquote cite="mid:20160820162046.GH19933@earth.li" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">As for the workload involved in dealing with wikis or CMS-s, were you
referring to content administration?
</pre>
</blockquote>
<pre wrap="">
I'm referring to the unfortunate way in which spammers attach themselves
to any uncurated website that allows anonymous or easy registration
submissions.</pre>
</blockquote>
<br>
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
<a class="moz-txt-link-abbreviated" href="mailto:webmaster@spi-inc.org">webmaster@spi-inc.org</a>.<br>
<br>
<blockquote cite="mid:20160820162046.GH19933@earth.li" type="cite">
<pre wrap="">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.</pre>
</blockquote>
<br>
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").<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<pre class="moz-signature" cols="998">--
Filipus Klutiero
<a class="moz-txt-link-freetext" href="http://www.philippecloutier.com">http://www.philippecloutier.com</a></pre>
</body>
</html>