1. Ores looks like a reasonable thing to implement, considering it's already in use in other language versions, and there are concrete steps that can be taken (training of the models). The training requires an active participation of the community, but considering the function has been of interest for over a year, and some of the training has already been done, there's a good chance some users will be willing to help out (especially the heavy vandal fighters, who will benefit the most).

Positive: 6
Negative: 0
Neutral: 0
Total: 6

2. Better WD support in infoboxes (not relying on fetching the whole WD item for every parameter) has certain support. The difficulties are: having to implement it in Lua and lack of good examples in other projects. A possible solution with metatemplates included in modules looks promising.

Positive: 5
Negative: 0
Neutral: 1
Total: 5

3. Wikidata-powered template for artworks. Technology-wise it's the same as the abovementioned, just with a very limited scope. Weak support because of that. A possible problem is that Wikidata items for artworks can contain a lot of detailed information that a human editor would put in the article text rather than in the infobox, so it would have to be processed in a sensible way.

Positive: 1
Negative: 0
Neutral: 1
Total: 1

4. Citoid library for Swedish sources. The Citoid infrastructure is already implemented, but has to be filled with (most popular) sources relevant to the Swedish-language community. Good support, and would benefit both editors and readers a lot. Very useful to new editors who today might feel discouraged by the unwieldiness of providing nicely formatted references, especially editors coming from an academic background.

Positive: 4
Negative: 0
Neutral: 0
Total: 4

5. Automatic formatting of pure url references. Solves a very common problem and has good support. Could be combined with the Citoid library above.

Positive: 5
Negative: 0
Neutral: 0
Total: 5

6. Convert incorrectly used source templates. Citoid often uses a wrong template for a given source (e.g. magazineArticle instead of website) and correcting it manually takes a lot of human resources. Can be combined with the other reference-related tasks. Weak support.

Positive: 1
Negative: 0
Neutral: 0
Total: 1

7. Simplify illustrating articles in the normal editor through a gadget similar to the built-in functionaly in Visual Editor (detect if article has no illustration and search Commons using the article title). Potentially includes marking images that should not be suggested -- this could result in a very large database. There's also a need for a tool that makes it easier to find articles without images in the first place. Very weak support.

Positive: 1
Negative: 1
Neutral: 0
Total: 0

8. Automatic signing in discussions using a bot. A problem that has been recognized for a while and is currently handled manually. There are good solutions in other language versions. Could also be accompanied by an edit filter marking unsigned discussion edits in the Recent Changes. Weak support -- it's a simple bot that can be handled by a single volunteer; there is a willing individual.

Positive: 1
Negative: 1
Neutral: 2
Total: 0

9. Notifications for IRL meetings. Weak support. On the one hand, it benefits a small target group and does not facilitate the actual work of editing Wikipedia; not an effective use of resources. On the other hand, it could encourage new editors to engage more in the community, and the solution could be appreciated and re-used by the other language versions as well.

Positive: 2
Negative: 2
Neutral: 0
Total: 0

In order of support:

6 -- Ores
5 -- Better WD support in infoboxes, Automatic formatting of url refs
4 -- Swedish sources for Citoid
1 -- WD supported infobox for artworks, Convert incorrect source templates,
0 -- Simplify illustrating articles in the normal editor, Automatic signing of discussion entries, Notifications for IRL meetings

Here are my thoughts. I realized that a lot of them deal with wiki-specific stuff I have little or no previous experience with.

Using the same numbering as above.

1. It's a bit unclear how far this would go; as I understood it, ORES have several components: training, varying type of application (which requires different sort of training). It sounds like the goal is to have automatic vandalism detection. Automatically rolling back is also mentioned; I don't know if this is something built into ORSE or if that would be an extra component. As @Alicia_Fagerving_WMSE mentions, actual data will have to be generated by the community, so we'll have to make sure that doesn't become a bottle neck.

2. I don't have that much experience with templates and "lua things", nor the Wikidata API, but I this kind of optimization shouldn't be too hard, I hope.

3. Don't really know enough to say much about this, apart from, as mentioned in the discussion, this sounds like it could be incorporated in 2.

4. Sound like this would be extracting information from different sites used as reference. Generally, I'd say this isn't that hard, but can vary widely on the site and code reuse between sites will probably be quite low.

5. Seems to share functionality with 4.

6. Also related to 4 and 5?

7. Seems doable, depending on API's etc. Not sure how easy it is to find relevant images.

8. From my experience with bots, this shouldn't be too hard. There are some discussion about when the bot should trigger that needs to be decided/tested.

9. The core functionality (reading page, showing notification) shouldn't be too hard. Figuring out the the opt-in/opt-out and how to present it may need some designing and planing.

OK here are my thoughts. Same numbering as above but I'm skipping those which didn't get any votes.

1. This primarily seems to need a project manager rather than any developer effort if I'm understanding things right. I.e. someone needs to organise people to do enough labelling then request that it gets turned on. reverted is done already, damaging +goodfaith need more data and we could possibly also suggest starting training for draftquality.
   • Conclusion: Big pay-off for a relatively small input from our side. Also has the benefit that some of the work can be outsourced to non-developers.

2. Some big improvements have been done here already. There are also some good examples developed on other wikis which can probably be imported and only slightly modified (to add improvements that we have today). It might be easiest to import one of these mature set of templates+modules then ensure that everything which worked for us before still works.
   • Conclusion: Large chance that most of this can be done by connecting with the developers on a few other language versions (Basque, Catalan and Russian wp). If we can get this to work then the upsides would also tie in nicely with the work done in Connected-Open-Heritage and WMSE-WFD-data-to-Wikidata-2016 etc.

3. Construction of a sv.wp specific template + supporting lua module for artwork.
   • Conclusion: I would say that if we do 2 then this could be included as a proof-of-concept. Otherwise it is probably not worth it.

4. I talked to Pigsonthewing at Wikimania who said that he had been involved with writing a few of such modules. He estimated that it takes about half a day to write one once you know what you are doing. This project has the benefit that it is useful not only to Wikipedia but also to the larger Zotero community. There seems to be some tooling around for developing such modules so one doesn't need to do it from scratch. An addition to the original wish was to build a framework that makes it easy for a non-developer to do the initial mapping (or to generate the script from such a mapping).
   • Conclusion: This s probably worth doing since it also affects a few of the other wishes. it also has the benefit that it is easy to adapt the number of supported sources to the time we have in the project. The framework for non-developers would probably be the best way to go but I'm unsure if such a thing can be built and especially if it can be built within the scope of this project.

5. This essentially boils down to a gadget which scans a page for pure-url ref tags. If found it runs the url through citoid and asks the user if (s)he wants to do the change. If so it replaces the url with the citoid output. You can also add an in-between step where you only suggest the change if the url is on a list of domains we know citoid supports properly (see 4).
   • Conclusion: This would probably be a gadget that would be of use to any wiki which uses VisualEditor. The quality of the result would however heavily depend on how well citoid deals with the urls. As such I would say 4 is more important (for sv.wp) but if time permits this would be a worthwhile complement.

6. This would be a very sv.wp specific mapping of template pairs in conjunction with a gadget that somehow allows you to select a given template for conversion. My guess is that the second part is distinctly more complicated than the first.
   • Conclusion: I got the sense that there is not a clear consensus on whether this was needed or if a better solution is to just use one template with a parameter controlling the layout. As such I think it might be worth skipping this for now.

On a finishing note: 1, 2 (if not built from scratch), 4 and 8 all fit the description "adapt a feature for sv.wp" whereas the others to a different extent require development from scratch of a new feature.

Meeting today decided to move forward with:

• ORES
• Swedish sources for Citoid with Automatic formatting of url refs done as part of this if time allows

The selected projects have been announced: https://sv.wikipedia.org/w/index.php?title=Wikipedia%3AGemenskapens_tekniska_%C3%B6nskelista&type=revision&diff=40810820&oldid=40723569