Hi Charles, Yes, the Terms of Use will apply. Please could you further clarify what you mean in your last line? As far as I know the editing community is responsible for enforcing this at all projects (except for the exceptions https://meta.wikimedia.org/wiki/Alternative_paid_contribution_disclosure_policies).

I'm not sure if you're suggesting that the software team should help to actively patrol new users and remind them of the disclosure requirements (for the first few months), or if you're suggesting we all ought to create an Alternative Policy for Wikifunctions specifically, or reminding us all to create a local copy/confirmation of the basic information like Wikidata has done https://www.wikidata.org/wiki/Wikidata:Disclosure_of_paid_editing, or something else entirely? Thanks, Quiddity (WMF)

On Sat, Nov 19, 2022 at 2:43 AM Charles Matthews via Abstract-Wikipedia < abstract-wikipedia@lists.wikimedia.org> wrote:

It shouldn't need saying that Wikifunctions will require compliance with the WMF Terms of Use:

https://foundation.wikimedia.org/wiki/Terms_of_Use/en

But I would like to say that anyway. In particular what is stated under "Paid contributions without disclosure".

I would like to be assured that these conditions will be actively enforced. By which I mean that these matters will not be delegated to the nascent community to raise and deal with.

Charles

On 17/11/2022 22:45 Denny Vrandečić dvrandecic@wikimedia.org wrote:

The on-wiki version of this newsletter can be found here: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-11-17 -- Code of Conduct for Wikifunctions

An important non-technical goal for Wikifunctions is to have a friendly and welcoming environment for newcomers, both for people from the existing Wikimedia communities and from beyond, right from the start.

A way to ensure that this will happen is to establish a code of behavioral policies, to which all the community members must adhere. As of now, we have several (non-exclusive) possibilities.

As a Wikimedia project, the Universal Code of Conduct https://meta.wikimedia.org/wiki/Universal_Code_of_Conduct will apply to Wikifunctions automatically. That is a great starting point.

The first question is: whether we should also adopt the Technical Code of Conduct https://www.mediawiki.org/wiki/Code_of_Conduct, which in some places is more specific than the Universal Code of Conduct. Since Wikifunctions is a technical project it seems to make a lot of sense.

The second question is: whether we should have some additional behavioral/conduct policies in place, which are either more specific or cover additional ground compared to the Universal and the Technical Codes of Conduct. Inspiration can be taken from the lists of existing behavioral/conduct policies https://meta.wikimedia.org/wiki/Wikimedia_community_code_of_conduct. Also in the case that we do not want to adopt the Technical Code of Conduct, we should write our own version of it.

I would like to see suggestions for policies around giving newcomers a bit of extra protection, particular given the complexity of our project. I'd also like to hear thoughts on policies regarding the multilinguality of Wikifunctions, which can hopefully learn from the best examples on Wikimedia Commons or Wikidata, the large multilingual projects we already have. Similarly, a policy that limits any discussion about “vim vs emacs” to no more than two posts per month per contributor could be needed, and some of you may have a few thoughts on how to avoid edit wars around code style.

As with the previous recommendation https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-09-27 for starting to draft a new policy before Wikifunction launches, we encourage everyone to discuss options, and perhaps draft content. Let’s centralize the discussion in this update's talkpage, and link to draft policies from there.

We will put a space where folks can state their agreement and disagreement with adopting the Technical Code of Conduct (as well as state their indifference, so we can estimate engagement). Besides that, the page is open for suggestions for further behavioral policies, and even drafts for these.

We are aware that we will not start with a perfect set of policies, and this is not the goal. The goal is to at least try to have the most important pieces in place from day one, so that we don’t start with an entirely blank slate. This is similar to the initial staff editing policy https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Staff_editing that was recently drafted. And just as with that policy, it is clear that the results are not written in stone, but will be amenable to change and will evolve as the actual community of Wikifunctions starts forming. But it is a good idea to have the first few guidelines at hand right from the beginning, and not to scramble reactively too much.

As it is always the case with such policies, a strong turnout would show a strong commitment to these policies. I hope that our nascent proto-community that is forming around Wikifunctions will show up and demonstrate our commitment to a set of policies that will lead to an inclusive and civil community in the future. Please take the time to let us know your thoughts. WikiConference North America

Last Saturday, we were presenting Wikifunctions virtually at the WikiConference North America / OpenStreetMaps USA. The session was recorded, but at the very end Denny’s Internet connection failed which took away that opportunity from the community to ask questions live. However, we still collected the questions and answered them on the wiki of the conference https://wikiconference.org/wiki/Submissions:2022/Wikifunctions_-_a_new_Wikimedia_project#Questions. Thanks to all attendees, and thanks for these great questions! Development updates

Experience & Performance

• Fixed more FE bugs
• Enabled websockets in the evaluator, allowing two-way communication

with orchestrator (T318359 https://phabricator.wikimedia.org/T318359)

• Implemented versioning of Avro schema (T321752

https://phabricator.wikimedia.org/T321752)

• Submitted fixes and test coverage improvements for current

perform_test flow (T321495 https://phabricator.wikimedia.org/T321495 , T321492 https://phabricator.wikimedia.org/T321492, T312290 https://phabricator.wikimedia.org/T312290)

• Made function view page implementation and test tables

mobile-friendly (T310162 https://phabricator.wikimedia.org/T310162)

• Implemented FE integration test for connecting implementations and

testers to functions (T318426 https://phabricator.wikimedia.org/T318426)

Meta-data

• Revised version finished: Record which implementation gets selected (

T320457 https://phabricator.wikimedia.org/T320457)

• Further work on caching tester results in MediaWiki DB (T297707

https://phabricator.wikimedia.org/T297707)

• Drop back-compat. code in orchestrator & evaluator (T291136

https://phabricator.wikimedia.org/T291136)

---

Abstract-Wikipedia mailing list -- abstract-wikipedia@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikimed...

---

Abstract-Wikipedia mailing list -- abstract-wikipedia@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikimed...

Charles,

Thank you for the clarification! That helps a lot. I agree with you that - particularly for Abstract Wikipedia - such a policy will be extremely important, as it would create content which will be served through numerous languages. This is one consideration we need to have once we get to the discussion about where Abstract Wikipedia should be stored.

Regarding Wikifunctions, I am much less concerned. Wikifunctions has, compared to Wikipedia or even Wikidata, much less of a potential to capture a conflict of interest: a function either does what it promises, or it doesn't.

Obviously, that is a naive baseline. After all, the whole idea of Wikifunctions is that functions are a form of knowledge, and therefore can indeed capture conflicts of interest, particularly as a library of function. I do expect that they do. But these issues should not become immediately pertinent, because we're going to start with functions such as adding numbers, or counting the length of a string.

Having said that, it is exactly this step now where we hope that the community will draft its first set of behavioral guidelines. So, yes, now is the time to also draft a policy regarding conflict of interests. I think your suggestion is a good and important one! There are many policy, guideline, and documentation pages that will need to be created.

For now we encourage in particular to consider the early drafting of two specific ones (Staff editing and ideas related to Conduct/Behaviour/Being welcoming) that we know it is important to have rough-outlines for, in place from the start.

Beyond that, I believe the standard practice is for most local policies and guidelines to be created "as needed" in the early months of a new wiki, in order to make them contextually appropriate based on any unique circumstances or issues that arise, and to enable the active community to guide those decisions/discussions.

The standard global policies will of course be in-effect, and experienced Wikimedians will bring familiarity with the usual best practices.

Cheers, Denny

On Tue, Nov 22, 2022 at 1:11 PM Charles Matthews via Abstract-Wikipedia < abstract-wikipedia@lists.wikimedia.org> wrote:

Nick,

Thanks for the link

https://www.wikidata.org/wiki/Wikidata:Disclosure_of_paid_editing

of which I was not aware.

It will help me clarify my concerns. I note that the page was created in 2020, which is quite some time after Wikidata was founded.

Without giving too many details, I'd like to mention that I was in discussion in 2019 with a bot operator on Wikidata, about some unsatisfactory edits. They were (clearly enough) related to some contract work being done.

I agreed to have a face-to-face discussion about the matter at WikidataCon 2019. When that happened, it was a tense meeting. The person in question was surprised and put out that I asked whether the editing was paid. But there was no clear statement. And it turned out that the need for a face-to-face was because the person was editing in bad faith on the Wikidata talk page of the bot, because management wanted it that way.

So this was a classic conflict of interest.

I was operating as an individual here. I sent an account of the business to Lydia Pintscher, but nothing happened as far as I know.

When I next had trouble with a bot operator, I just had to accept that some bad edits might or might not have been paid. I worked through an admin, and after nine months got something done.

The special circumstances here, that over 50% of edits on Wikidata have been made by bots, have I think led to a very lax approach to paid editing. This might have been predicted, but I think was not. In any case the community-led approach, such as obtains on enWP where Jimmy Wales took a tough line with paid editing early on, is very different. Wikidata for a long time got along with a soft redirect to meta as its statement of conditions of use.

I have no idea what the state of discussions of machine editing, or commercially-oriented editing, on Wikifunctions might be. I'm raising this now, because I think these matters should be aired.

Charles

On 22/11/2022 18:01 Nick Wilson (Quiddity) nwilson@wikimedia.org wrote:

Hi Charles, Yes, the Terms of Use will apply. Please could you further clarify what you mean in your last line? As far as I know the editing community is responsible for enforcing this at all projects (except for the exceptions https://meta.wikimedia.org/wiki/Alternative_paid_contribution_disclosure_policies).

I'm not sure if you're suggesting that the software team should help to actively patrol new users and remind them of the disclosure requirements (for the first few months), or if you're suggesting we all ought to create an Alternative Policy for Wikifunctions specifically, or reminding us all to create a local copy/confirmation of the basic information like Wikidata has done https://www.wikidata.org/wiki/Wikidata:Disclosure_of_paid_editing, or something else entirely? Thanks, Quiddity (WMF)

On Sat, Nov 19, 2022 at 2:43 AM Charles Matthews via Abstract-Wikipedia < abstract-wikipedia@lists.wikimedia.org> wrote:

It shouldn't need saying that Wikifunctions will require compliance with the WMF Terms of Use:

https://foundation.wikimedia.org/wiki/Terms_of_Use/en

But I would like to say that anyway. In particular what is stated under "Paid contributions without disclosure".

I would like to be assured that these conditions will be actively enforced. By which I mean that these matters will not be delegated to the nascent community to raise and deal with.

Charles

On 17/11/2022 22:45 Denny Vrandečić dvrandecic@wikimedia.org wrote:

The on-wiki version of this newsletter can be found here: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-11-17 -- Code of Conduct for Wikifunctions

An important non-technical goal for Wikifunctions is to have a friendly and welcoming environment for newcomers, both for people from the existing Wikimedia communities and from beyond, right from the start.

A way to ensure that this will happen is to establish a code of behavioral policies, to which all the community members must adhere. As of now, we have several (non-exclusive) possibilities.

As a Wikimedia project, the Universal Code of Conduct https://meta.wikimedia.org/wiki/Universal_Code_of_Conduct will apply to Wikifunctions automatically. That is a great starting point.

The first question is: whether we should also adopt the Technical Code of Conduct https://www.mediawiki.org/wiki/Code_of_Conduct, which in some places is more specific than the Universal Code of Conduct. Since Wikifunctions is a technical project it seems to make a lot of sense.

The second question is: whether we should have some additional behavioral/conduct policies in place, which are either more specific or cover additional ground compared to the Universal and the Technical Codes of Conduct. Inspiration can be taken from the lists of existing behavioral/conduct policies https://meta.wikimedia.org/wiki/Wikimedia_community_code_of_conduct. Also in the case that we do not want to adopt the Technical Code of Conduct, we should write our own version of it.

I would like to see suggestions for policies around giving newcomers a bit of extra protection, particular given the complexity of our project. I'd also like to hear thoughts on policies regarding the multilinguality of Wikifunctions, which can hopefully learn from the best examples on Wikimedia Commons or Wikidata, the large multilingual projects we already have. Similarly, a policy that limits any discussion about “vim vs emacs” to no more than two posts per month per contributor could be needed, and some of you may have a few thoughts on how to avoid edit wars around code style.

As with the previous recommendation https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-09-27 for starting to draft a new policy before Wikifunction launches, we encourage everyone to discuss options, and perhaps draft content. Let’s centralize the discussion in this update's talkpage, and link to draft policies from there.

We will put a space where folks can state their agreement and disagreement with adopting the Technical Code of Conduct (as well as state their indifference, so we can estimate engagement). Besides that, the page is open for suggestions for further behavioral policies, and even drafts for these.

We are aware that we will not start with a perfect set of policies, and this is not the goal. The goal is to at least try to have the most important pieces in place from day one, so that we don’t start with an entirely blank slate. This is similar to the initial staff editing policy https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Staff_editing that was recently drafted. And just as with that policy, it is clear that the results are not written in stone, but will be amenable to change and will evolve as the actual community of Wikifunctions starts forming. But it is a good idea to have the first few guidelines at hand right from the beginning, and not to scramble reactively too much.

As it is always the case with such policies, a strong turnout would show a strong commitment to these policies. I hope that our nascent proto-community that is forming around Wikifunctions will show up and demonstrate our commitment to a set of policies that will lead to an inclusive and civil community in the future. Please take the time to let us know your thoughts. WikiConference North America

Last Saturday, we were presenting Wikifunctions virtually at the WikiConference North America / OpenStreetMaps USA. The session was recorded, but at the very end Denny’s Internet connection failed which took away that opportunity from the community to ask questions live. However, we still collected the questions and answered them on the wiki of the conference https://wikiconference.org/wiki/Submissions:2022/Wikifunctions_-_a_new_Wikimedia_project#Questions. Thanks to all attendees, and thanks for these great questions! Development updates

Experience & Performance

• Fixed more FE bugs
• Enabled websockets in the evaluator, allowing two-way communication

with orchestrator (T318359 https://phabricator.wikimedia.org/T318359)

• Implemented versioning of Avro schema (T321752

https://phabricator.wikimedia.org/T321752)

• Submitted fixes and test coverage improvements for current

perform_test flow (T321495 https://phabricator.wikimedia.org/T321495 , T321492 https://phabricator.wikimedia.org/T321492, T312290 https://phabricator.wikimedia.org/T312290)

• Made function view page implementation and test tables

mobile-friendly (T310162 https://phabricator.wikimedia.org/T310162)

• Implemented FE integration test for connecting implementations and

testers to functions (T318426 https://phabricator.wikimedia.org/T318426)

Meta-data

• Revised version finished: Record which implementation gets selected (

T320457 https://phabricator.wikimedia.org/T320457)

• Further work on caching tester results in MediaWiki DB (T297707

https://phabricator.wikimedia.org/T297707)

• Drop back-compat. code in orchestrator & evaluator (T291136

https://phabricator.wikimedia.org/T291136)

---

Abstract-Wikipedia mailing list -- abstract-wikipedia@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikimed...

---

Abstract-Wikipedia mailing list -- abstract-wikipedia@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikimed...

-- Nick "Quiddity" Wilson (he/him) Community Relations Specialist Wikimedia Foundation

---

Abstract-Wikipedia mailing list -- abstract-wikipedia@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikimed...