Questions to answer during this session

Question	Significance: Why is this question important? What is blocked by it remaining unanswered?
Which content management and collaboration features could be useful for the WMF and chapters for internal use and community collaboration that are currently only used by 3rd parties?	There may be features provided by extensions that are frequently used by 3rd parties and may also be useful for the WMF and chapters. These are not features for managing encyclopedic content but rather features that could help the internal workflows of the WMF and chapters. Developing and supporting these extensions increase productivity, allowing us to use our own software better. With the additional support of WMF, these extensions could also have increased quality and security.
Should access control be a core feature of MediaWIki and, if so, at what level of granularity? Should draft pages and an approval mechanism be a core feature of MediaWiki? What trade-offs and blockers are involved in providing this functionality?	The current design of MediaWiki does not support page level access control in core. This cannot be added comprehensively in an extension without leaving potential vulnerabilities. If these are desired features, architectural support will need to be provided in core.
How do storage and query/visualization of structured data augment 3rd party MediaWiki usage? What approaches are used (e.g. Wikibase/Wikidata, Semantic MediaWiki, Cargo, or others) and why? What approaches are most useful in what situations?	While other sessions will discuss implementation options, this session will address what use cases for wiki-based structured data exist and their benefits. This will help guide later implementation focused discussion.
How important is it to have an integrated discussion system for MediaWiki? What level of granularity should be supported (per page, per revision, on sentences or phrases, on citations, etc.)? What additional features are helpful (moderation, voting, etc.)? How do talk pages fit in? What has worked well? Not so well?	This can help drive features for future enhancements to on wiki discussion systems.
Which features that are currently developed and maintained by the WMF are NOT useful to 3rd parties? For example, is CentralNotice useful to 3rd parties?	For features not used by 3rd parties, architectural constraints (e.g. implementation as a service or requiring installation/configuration of additional software) are removed and no resources need be directed at packaging for reuse.

Structured notes

Questions and answers

Q: Which content management and collaboration features could be useful for the WMF and chapters for internal use and community collaboration that are currently only used by 3rd parties?
A (If you were unable to answer the question, why not?): None were identified.

Q: Should access control be a core feature of MediaWIki and, if so, at what level of granularity? Should draft pages and an approval mechanism be a core feature of MediaWiki? What trade-offs and blockers are involved in providing this functionality?
A (If you were unable to answer the question, why not?): One group (out of three) selected this topic and said that it should be in Core. Draft pages and an approval mechanism were not specifically discussed. A current solution [what?] exists but has fundamental problems (e.g., leaks info).

Q: How do storage and query/visualization of structured data augment 3rd party MediaWiki usage? What approaches are used (e.g. Wikibase/Wikidata, Semantic MediaWiki, Cargo, or others) and why? What approaches are most useful in what situations?
A (If you were unable to answer the question, why not?): Not answered because this topic was not among those chosen for further discussion by the small groups.

Q: How important is it to have an integrated discussion system for MediaWiki? What level of granularity should be supported (per page, per revision, on sentences or phrases, on citations, etc.)? What additional features are helpful (moderation, voting, etc.)? How do talk pages fit in? What has worked well? Not so well?
A (If you were unable to answer the question, why not?): Two groups thought that better collaborative editing tools were important to work on and useful for everyone, and should be in the default install. This was the feature most cited as missing in MediaWiki for collaboration.

Q: Which features that are currently developed and maintained by the WMF are NOT useful to 3rd parties? For example, is CentralNotice useful to 3rd parties?
A (If you were unable to answer the question, why not?): None were identified. However, insufficient access control was cited as the single most important blocker to collaborative use.

Features and goals

For Use Case and Product Sessions: Given your discussion of the topic and answering questions for this session, list one or more user stories or user facing features that we should strive to deliver
1. Access Control
Why should we do this? Useful for all MediaWiki users.	What is blocking it? n/a	Who is responsible? Core Platform Team
2. Real-time collaborative editing
Why should we do this? Useful for all MediaWiki users.	What is blocking it? n/a	Who is responsible? Core Platform Team, maybe other product teams
3. Workflows, Annotations, Discussions
Why should we do this? Each is useful for certain collaboration use cases.	What is blocking it? n/a	Who is responsible? Core Platform Team, in the first instance

Important decisions to make

What are the most important decisions that need to be made regarding this topic?
1. How should we prioritize work on the five collaboration features identified?
Why is this important? Because our engineering resources are limited.	What is it blocking? Any progress on this topic.	Who is responsible? Core Platform Team

Action items

What action items should be taken next for this topic? For any unanswered questions, be sure to include an action item to move the process forward.
1. Collect more information on installed extensions, what versions people have installed as part of the Pingback mechanism (https://phabricator.wikimedia.org/T200375)
Why is this important? Having this information will inform (but not define) our answer to Question 1.	What is it blocking?	Who is responsible? Core Platform Team

New Questions

What new questions did you uncover while discussing this topic?
What is the definition of a “barebones” installation? Should the default install be a “barebones” installation?
Why is this important? We need to be deliberate about what functionality is included and will need support “out of the box.”	What is it blocking? This is necessary to resolve when deciding what additional collaboration tools to bundle with MediaWiki (and what support, if any, to build into Core).	Who is responsible? Core Platform Team (?)

Detailed notes

This session is about MediaWiki as a tool for collaborating on knowledge creation/mgmt
There are lots of people already doing this
First activity (already started in hallway) was to ID features that help facilitate collaborative uses of MediaWiki and things that make it harder or are missing
First activity here (~10 mins) is for people to get up and walk around to discuss three topics (see session structure for the topics)

First exercise: Post-it stations

A Features that 3rd party users use for collaboration (High priority first)

B Features that currently prevent using MediaWiki for collaboration and instead another tool is used

(In group discussion: PDF export missing? Actually, this exists, but not from the “print” menu option in the browser, which a savvy user may expect.)

C Features that are supposed to be used but are missing key pieces

(In group discussion: templates for license info? This is because at one company, lawyers aren’t satisfied with the license for a work simply being listed on a page)

Issues prioritized through voting for each group:

A Features that 3rd party users use for collaboration

Access Control (3rd party users use)

B Features that currently prevent using MediaWiki for collaboration and instead another tool is used

Collaborative Editing (missing)

Live Chat/discussions (missing)

C Features that are supposed to be used but are missing key pieces

Workflow

Annotations/comments on specific parts of a page (exists but needs improvement)

Group 1

Live Chat/discussions (missing)

Who is the feature useful for:

3rd parties
Wikimedia contributors
Maybe everyone :-)

Note:

You have to have a common topic, that you want to discuss, or it would be interesting for asking for help. Unmoderated chatroom would be dangerous, but if it is focused to e.g. a page, it can be very useful.
No need to record it.

What extensions are already existing?

Flow
Might become a side feature of the real life collaboration project (collab pad)?
PM extensions?
MediaWiki chat (stable) ?

Should we have this available as barebones MW install?

Should be offered as an easy to get extension

Workflow

Who is the feature useful for:

Potentially more useful for Wikipedia contributors; but might have a wider potential audience

If you think about reviewing content, it might be interesting for companies as well

What extensions are already existing?

Flagged revs?
Guides tours (creation of workflows around tours)

Should we have this available as barebones MW install?

Would not expect to have that
Different communities/users might have very different view on workflows
Both examples above are used in various WM projects

Annotations/comments on specific parts of a page (exists but needs improvement)

Who is the feature useful for:

Wikipedia, Wikidata, 3rd Partys (everybody)

What extensions are already existing?

Maybe. There is a Annotations extension (unmaintained since a very long time) (https://www.mediawiki.org/wiki/Extension:Annotation ?)

Wikiblame

The functionality might be part of other features.

Should we have this available as barebones MW install?

Definitely

Large group (Sage’s notes to be digitalised)

Access control

Useful for: Everybody

This exists in some form but has problems in that it leaks info. Probably belongs in Core, wanted in barebones install.

Group 2

topics

- Annotations

- Collaborative editing

- Workflows

* Collaborative editing

Who is it useful for?

- everyone, it's an objective good

- (but maybe not for WP articles?)

What extension does this already exist in?

- NONE

- Coming in VE?

- Daniel: Problem is that it doens't fit with the revision model at all

- Karsten: What use cases is it useful for? Creating minutes of meetings such as the one we're having here, for one.

Part of barebones MediaWiki?

- As a MW dev I'd say no b/c it's quite foreign to how MW works, but as a user I think it's functionality I would expect

- I would not put it in Core..

- CC: I would put it in Core if there are scalability concerns. Or it could be a separate extension with Hooks in Core

- Karsten: Needs to be stable across MW versions

- Daniel: Core would need support for it, but a barebones install may not include it

- CC: If this is a collaborative tool (???)

- Erik: Imagine heavily edited articles -- we wouldn't want to see every keystroke...

- Daniel: So maybe it shouldn't be enabled for Wikipedia

* Annotations

What does this actually refer to? Notes on sections of pages? Per-sentence tracking?

EB, Daniel: This is actually a really hard problem

Who is it useful for?

- definitely Wikpedia, third parties, Small scale collaboration

What extension does it already exist in?

- Citations might be an example of it

- Alex: I think of annotations as, e.g., highlight sentence and flag for moderation

- Dbrant: In the mobile world there's a big need for social highlighting, this could be a use case

Also in Wikiblame

(other groups: Hypothesis, Image annotations functionality, Annotations extension)

Does it belong in a barebones install?

- Daniel: Core needs to support it. But we've been talking about three different kinds of annotations, should they all be in by default?

Probably not.

* Workflows

What does this refer to? This is what Flow was supposed to do, right?

Article creation is a workflow. Articles for deletion is a workflow. Making someone an admin or bureaucrat, etc. is a workflow. Deciding article quality is a workflow.

Daniel: But you can also model workflows as pages.

Useful for?

- WP

- Third parties

Already exists in?

- Individual flows exist on many wikis via gadgets, don't know of extension

- FlaggedRevs

- ApprovedRevs

Belong in base MW install?

- Most wikis don't need it (Daniel)

- Sort of against the nature of a wiki (Daren); sort of slows things down (which may indeed be their purpose)

- Should we even attempt to deal with the concept of a workflow generically

Group 3

collab editing

Live chat/discussions

Who useful for? everyone

What extensions exist in? Flow, CollabPad, VE, bunch of others

Expect to be in barebones install? We'd expect something better than Talk pages but not necessarily full-blown chat

Workflows

Open questions:

Does barebones = default = Core?

Erik: When you put something in Core, you're enforcing a solution

Daniel: When we look at these things, some (annotations) need need conceptual support in Core even if they are ultimately implemented in extensions. But others do not (Workflows).

Erik: What about Core support for, e.g., a state machine?

Karsten: I think Core should have notifications support, I was surprised it wasn’t chosen because it was quite important.

Middle group: open questions:

-We decided that lockdowns approach in scope was demonstrated to be useful in most actual use cases. Taking that as a good starting point for requirements and moving to Core would be the way to go.