On Samstag, 17. September 2016 16:00:44 CEST Jonas Oberg wrote:

The alternative is to not require a login to edit. I think this can be set with an acl on specific pages. Right, caretakers?

Yes: #acl Group/WikiCareTakers,jzarl:read,write,delete,revert,admin All:read,write

To try it out: https://wiki.fsfe.org/Fellows/jzarl/SandBox/public

On the other hand, non-authenticated edits always require the user to submit the text-captcha (which might be annoying to some people), and there is no proper attribution...

Cheers, Johannes

How about a slight streamlining of the existing procedure?

Add a field to the account creation form: "Referral (Email address of the person referring you)"

Then we can write TechDocs/AccountCreation with less steps:

######################## == Account creation steps for volunteers ==

1. Register for an account You will receive an automatically generated password - hold on to it! 2. We will contact the person who referred you for details 3. We will inform you when your account is ready

=== Activating your account === Once your account is ready, you can activate it:

1. Log in with the password that you received 2. Choose a username and review your account settings 3. Change your password

Once you've set up a username, you can use our [[TechDocs/FellowshipServices| services]] and make changes to our wiki. As a starting point, check out [[TechDocs/Wiki]] ########################

I omitted the first two steps ( deciding where to contribute, get in touch with a coordinator) on purpose. I think that the likely situation when somebody wants to contribute as a non-paying volunteer is that he/she already knows someone of the FSFE that can vouch for the person.

Not necessarily. Can't we consider the wiki a special case? Why does the subscription to the wiki necessarily need to be validated by a coordinator, etc.?

While I do think that it's a good idea to have some validation (i.e. somebody vouching for the new volunteer), I think the existing steps are indeed overly complex and a potential barrier.

Cheers, Johannes

hi, On Sun, Sep 18, 2016 at 07:46:08PM +0200, Jonas Oberg wrote:

Hi,

...

Not necessarily. Can't we consider the wiki a special case? Why does the subscription to the wiki necessarily need to be validated by a coordinator, etc.?

I'm not sure we want yet one more special case. We already have one for the web pages and trac, and introducing the current mechanism was to avoid such special cases :-)

I would be happier if we make the registration process easier though. That it currently requires a coordinator to validate the account is because it involves some manual work.

well, special cases should be avoided if possible. also: even when we had guest accounts in the wiki, we requiered aproval and manual activation because we had lot's of spam registrations...

also, i would think if somebody want's to do a real contribution, the contact point to somebody within fsfe and therefore the extra burden is minimal imho.

from my expirience, lot's of smaller wiki installations requiere manual registration ("send an email to that address if you want to have an coount") nowadays, as otherwise combating wiki spam is quite a bit of work.

the other question is: for people who just want to do one or two edits, obviously the burden is relativ high if they don't want to become regular contributers...however, the question is how much would we gain from these people, given that our wiki is used to coordinate our activities/work or document our infrastructure.

regards, albert

Thanks for summing up. Let me correct one bit.

Le 28 septembre 2016 21:16:53 GMT+03:00, Johannes Zarl-Zierl jzarl@fsfe.org a écrit :

(2) Hugo mentioned that this is not a solution, as it does not allow people to subscribe to wiki changes. He said the current process deters people from getting an account, and that he feels that validation by a coordinator should not be required. Hugo then suggested that we could make wiki accounts a special case, i.e. allow wiki-only accounts in addition to full accounts (if I understood that correct)

I don't think the ability not to be able to subscribe to changes is a big issue.

My issue is mainly with lowering the bar for contributions to the wiki.

If the policy is to make the wiki editable by anyone then the current process is way too cumbersome. But from what I understand there is disagreement or lack of clarity on what the policy is. IIRC Albert thinks we should have a quite high threshold to contribute to the wiki (by having to go through someone). I don't see the benefit of that policy. I see practical issues such as spam but I think there are probably easier solutions to such issues.

Anyway. The policy should be stated on the wiki itself in an easily accessible manner. When I sent my original email the info was just not there to be found.

So thanks for fixing that :-)

Hi Johannes,

(3b) I suggested to make the process less complicated. In particular to require fewer communication round-trips for the new volunteer. Suggested wording: [1] Any position on that?

Ah, I might have forgotten to say. I agree with making the process easier and in the specifications for the new account management system, I've included this as a requirement for the first step (we'll start looking for an intern to help with writing this in a week or two).

The reason we can not do it in the short term is these two steps:

1. Register for an account 2. We will contact the person who referred you for details

The registration form doesn't have a field for referrals, and there's no easy way to store this. So we don't have any way to know where the person comes from to ask for details. That's why we had the step in the process so far that the coordinator needs to have some role in this to be more active in the communication with fellowship@ so we can authenticate the registered volunteer.

We might be able to do something on shorter notice than rewriting the account system. I could hack the registration form to have something in there but in order to make this reasonable, there's one thing which is desperately missing and which has been missing for some time:

A LIST OF TEAMS :-)

It's on my list to clarify which teams we have and put the information about them on the wiki, including getting in touch with the coordinators and making sure we and they *know* who the coordinators are. I'd also want to create a handbook for coordinators on the wiki.

If someone is interested in some extracurricular activities on helping me with this, I'd be happy for any help :-)

Hi Johannes,

I can do some proof-reading and cleanup for the texts, but very probably not more...

Here's something you can do :-) (Or someone else with wiki knowledge more than me..)

We have the Teams and LocalGroups namespaces, but this misses a little bit the country teams. In order to make our teams easy to find, it's not very suitable if the WikiCaretakers team, for instance, is listed together with 20+ country teams (ideally).

What I would love to have, and please give comments on this, is a Teams page structured something like this:

Blah blah introduction

Topical teams ------------- System-hackers WikiCaretakers Translators ...

Country teams ------------- Austria Nordics France Germany ...

Local groups ------------ Aberdeen Bari Berlin Athens Vienna ...

There's not so many teams that it's not possible to include them on the same page, if it's technically doable. I guess the only issue would be how to separate a *Country* team from a *topical* team.

Sincerely,

Hi,

I'm including Erik in this discussion for input, and Fernando, as I hope Fernando can help with some work on this once we establish the parameters. To start: this is about getting our Teams onto the wiki.

This was my thoughts:

We have the Teams and LocalGroups namespaces, but this misses a little bit the country teams. In order to make our teams easy to find, it's not very suitable if the WikiCaretakers team, for instance, is listed together with 20+ country teams (ideally).

What I would love to have, and please give comments on this, is a Teams page structured something like this:

Blah blah introduction

Topical teams
-------------
System-hackers   WikiCaretakers   Translators ...

Country teams
-------------
Austria      Nordics     France    Germany ...

Local groups
------------
Aberdeen   Bari   Berlin   Athens  Vienna ...

jzarl suggested using categories to separate topical and country teams, so we would have two categories:

Category/CountryTeam Category/TopicalTeam

And the teams otherwise sorted in the namespaces LocalGroups/ and Teams/

In addition, we also have a category for inactive teams:

Category/Inactive Category/Active

And each local group also has their own category, for instance Category/Austria.

I think this all makes sense as a structure, and would be easily achievable based on what we now have.

What we are missing are reasonable templates. We started using one for our teams, but I think we also need to have something for the local groups. To start this, we need to define what information we expect any team to fill out on their page. They may add additional information, of course, but the basics should be there.

From my side, I would like each team or group to have information

about:

The coordinator and (if appointed) deputy coordinator The mailing list(s) used for exchange between members A 1-3 sentence description of the team Information about how someone becomes active (join mailing list, get in touch with coordinator, etc)

Hi Johannes,

We currently only use Category/Inactive for the reasons stated above. You can always negate a category search: "-category:Category/Inactive"

Right, good point. So only Category/Inactive then.

I'm not sure if we are on the same page here. As currently used, the Category/ <Country> categories are intended to mark country-specific information.

Ah! I see, yes, that makes sense. So let's keep it in this way.

I would also like some guidenance about the language used for that information. Based on my experiences with the Teams template, I would say that having the information in English benefits us wiki caretakers. OTOH "normal" readers of those pages should be able to read the information in their native language (this is even more important for local group pages).

Maybe a bilingual information block would be a compromise?

That's a good point. Do you think this should or could be explicit or should we just encourage people to add bilingual information to existing fields where relevant? For instance:

Description:: A group about Free Software in Sweden / En grupp om fri programvara i Sverige

I'm slightly in favor of this, as I would not expect more languages than one version in English and one in the native tongue for the group. Well, aside from complicated regions where you may have

Description:: English / Dutch / French / Flemish

:-)

Sincerely,

Hi Jonas,

On Freitag, 18. November 2016 10:24:54 CET you wrote:

I've now created a draft page with the information we discussed:

https://wiki.fsfe.org/Teams/WikiCaretakers/TeamPages

The purpose of this page is not yet fully clear to me: is the draft for the soon-to-be "team portal", or is it meant as a documentation page for how we organise teams?

If this is the portal page, I would recommend (and maybe volunteer) to simplify the page. If it's "just" documentation, then it is mostly ok (I've done some readability-tweaks).

(it may belong somewhere else once it's no longer a draft, but suggestions welcome).

If it's the portal page, then it should go to "Teams", otherwise somewhere in "KnowHow". Maybe we should create a section "KnowHow/Organisation" or something like that...

I also updated the template a little bit (and included some comments in it, especially about the language use).

https://wiki.fsfe.org/Template/Team

Looks good to me...

Cheers, Johannes

On Wed, Sep 28, 2016 at 08:16:53PM +0200, Johannes Zarl-Zierl wrote:

To summarize the thread up to now:

Thank you very much, for doing this. I'll reply to the points in altered order.

(3a) Jonas and Albert were against indroducing special cases, and implied that wiki-only accounts would still require manual intervention, thus having the same workload for less benefit.

To point out the history behind this: switching off local authentication in the Wiki was one of the major reasons, why we introduced the volunteer accounts in the first place. Until then we were running custom patches in the Wiki software to enable local accounts alongside accounts from the fellowship LDAP. With insufficient spam protection in Moin manual filtering of account requests was required and tedious, and neglected as a result.

The very same account creation process is now simply relayed to our main account management for volunteers.

Writing custom patches for the new Wiki setup again, would be a horrible regression, not to mention a bad precedent for other services, and I frown at the very contemplation to do such a thing.

(1) Jonas observed that it's also possible to make pages world writable.

I would encourage people to do this for pages which ought to be edited casually by a number of people. I imagine local fellowship groups, with subpages for their particular activities, to be the main but not the only beneficiaries here.

(2) Hugo mentioned that this is not a solution, as it does not allow people to subscribe to wiki changes.

Looking for a technical solution, I notice that Moins RSS feeds are not really clickable in the web interface.

An RSS feed for every page can be obtained by appending ?action=rss_rc to the page url. No form of account is required for this.

He said the current process deters people from getting an account, and that he feels that validation by a coordinator should not be required.

I agree with this point, but I believe this ought to be a discussion in the context of how we handle volunteer accounts, not in the context of the wiki.

Hugo then suggested that we could make wiki accounts a special case, i.e. allow wiki-only accounts in addition to full accounts (if I understood that correct)

If our policies regarding volunteer accounts are insufficient for the Wiki then other services will be affected too, as we introduce volunteer run services and extend our infrastructure. What I could rather imagine making the Wiki a special case for, is as an indicator for our requirements to enable external contribution.

(3b) I suggested to make the process less complicated. In particular to require fewer communication round-trips for the new volunteer. Suggested wording: [1] Any position on that?

I feel, that so far we are handling the volunteer signup as a kind of insiders tip for special cases. I for one would be in favour of making the volunteer signup more open, but I suppose this decision will involve the core team and fellowship coordinators much more than the WikiCareTakers. From the AMS-Hackers perspective I expect this to be a non-issue.

In the light of a respective decision we would link to the volunteer signup where a Wiki account creation page would otherwise be.