Re: Issue #2 - Allow contributions to website from browser

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 webmaster(at)spi-inc(dot)org(dot)

> 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