Project talk:New contributors/Roadmap

Previous page history was archived for backup purposes at Project talk:New contributors/Roadmap/LQT Archive 1 on 2015-07-10.

This is one of the first features in the development queue.

User profiles would have several form fields in addition to the MediaWiki stock textarea and User_Talk page. Let's forget about "following" options for now.

Let's agree on the plan:

• Textfields with autocompletion for interests, locations, languages and projects.
• Regular textfields for media handles: Twitter, Facebook, Google+, identi.ca.
• Upload file for avatar. Nice if we can have size limit and license check like with regular image uploads but otherwise we can just pass for the proof of concept.

That's it. How complex is to implement this in a wiki with SMW and SemanticForms already enabled? And just to have an idea, how complex would be to get this functionality without SMW?

There are some benchmarks defined for this feature. Your feedback about these is welcome as well:

• How evident and inviting is this feature for new users?
• How easy to define existing and new interests?
• How easy to modify or remove interests?
• Do the user profiles look good?
• Can other users mess with your profile?
• Are there privacy questions or concerns?

This post was posted by Qgil-WMF, but signed as Qgil.

For starters, I created a quick rudimentary user profile form/template (see [1], [2], [3], [4]) which you can copy to wikitech and start playing around with it. The form and template are straight forward (no design features, includes textfields with autocompletion, upload field for an avatar) but it should give you an initial idea how things can be done.

• [1] http://www.semantic-mediawiki.org/wiki/Template:Userprofile
• [2] http://www.semantic-mediawiki.org/wiki/Form:Userprofile

• [3] http://www.semantic-mediawiki.org/wiki/Demo:Userprofile
• [4] http://www.semantic-mediawiki.org/w/index.php?title=Demo:Userprofile&action=formedit

Thank you MWJames! That was fast.

I have requested a wiki in Labs for testing and prototyping without compromises or special permissions required, and without messing with community feelings or expectations. I will post here once we have it approved then anybody will be able to help directly.

This post was posted by Qgil-WMF, but signed as Qgil.

The current listed plan is to create a new MediaWiki extension that will enable all information relating to a specific "Node" (interested users, relevant bug reports, related events and news, etc.) to be aggregated and displayed on the page for that node. This might not actually require an extension at all - it might all be doable using a combination of Semantic MediaWiki and the External Data extension. External Data lets you get structured data from an API - so the key is just to make sure that there are APIs to get all the relevant information out of Bugzilla, Gerrit, the Wikimedia blog, etc. If there aren't APIs right now to handle all of that, that might require some programming - but I think that would be an easier and more flexible solution than creating a whole extension just for this purpose. More flexible in the sense that all formatting of values would be done within wiki pages - so modifying the look of any of it, or, say, the number of rows displayed for each data type, could be done within the wiki, as opposed to requiring changes to the PHP code.

Interesting! The only reason to suggest an extension was not to mess with the rest of the system. If Nodes can be created just by configuring properly the system, then all the better.

We could start iterating on Nodes without External Data, simply with data available in the own wiki. For instance, the first Node features proposed here requires that

• Category pages aggregate automatically related events and users.
• The content area is as editable as a regular category page.

For example: "Node:Lua" starts with the plain editable textarea, followed by a list of users (only names linked to profiles) following the Lua category, and Lua events in the right column.

Once this piece is working we would consider more entities from within the wiki: projects and tasks.

When we reach this stage we can consider external data: Wikimedia Blog entries, Bugzilla and Gerrit. But I wouldn't put too much thought on these at this point.

This post was posted by Qgil-WMF, but signed as Qgil.

After a few months of Groups we have seen that making everybody go through the Wikimedia User Group process (or any process) won't work, no matter how light that process is. Still, everybody agrees that grouping the people interested around a topic is useful...

The new formulation of Groups tries to address this. Wherever there is a tag there will be a Group listing the people related to that tag. How active and structured a Group is will depend on the activity of the people around it: it can go from zero (with zero cost) to an official WUG organizing local events, with all the shades in between.

The basic functionality might be provided by the Category features, or at least they have many common similarities.

This post was posted by Qgil-WMF, but signed as Qgil.

By "tag", do you mean the same items people use on their profile to express interests?

I think it's what you mean, and it makes sense to me, but I just want to check to be sure. If so, we might just want to call them "Interests" (the term seems to encompass topical groups like "Promotion" as well as other groups like LUGs).

Yes, but not only interests. There would be also groups around locations, languages and OSS projects. I've tried to explain it better at the Groups section.

This post was posted by Qgil-WMF, but signed as Qgil.

Maybe Semantic Forms would be enough to implement Groups? Let's look at the features:

Group page creation

1. Mary is the first user that defines in her profile a "JavaScript" interest subscription.
2. A page Groups/JavaScript is created automatically, listing Mary under the interested users list.
3. Users can watch / edit / discuss in the page & related Talk page, but they can't remove or manipulate the list.

More users join / leave

1. Other users declaring their interest in "JavaScript" in their profiles will be added to the list.
2. When a user deselects "JavaScript" in their profile they are removed from the list.

Joining / leaving from the group page

1. John finds the Groups/JavaScript page and he clicks the "Join" button.
2. John is added to the list. "JavaScript" interest is selected in her profile now.
3. John realizes that he meant "Java". He clicks the "Leave" button, is removed from the list and his profile reflects the change.

Is this feasible with Semantic Forms alone?

And now as a bonus: could we add attributes to the "JavaScript" interest that would affect the presentation of the list?

1. Mary is simply interested. She wants to be seen in the list but that's it for now.
2. John has an interest in JavaScript after all, but he doesn't want to appear in the JS list. He clicks the "No list" checkbox.
3. JoSephine is so much into JS! She wants to contribute actively to the group activities. She clicks the "Contributor" checkbox.
4. The list shows first JoSephine under Members and then Mary under "Also interested". There is no public trace of John there.

This post was posted by Qgil-WMF, but signed as Qgil.

The main part, about being able to have "Join" and "Leave" buttons in order to add or remove oneself from a list on the page, is not yet doable in Semantic Forms, though it's a feature that I've long wanted to add, and this would be a great opportunity to add it in. From a technical standpoint, it would involve adding to the #autoedit parser function the ability to add and remove elements to/from a list, instead of just overwriting that list. I think it's quite doable.

As for the "bonus" stuff: most of it is probably doable in the same way, using multiple lists on each page (members, contributors, interested users) instead of each one. It couldn't be done with checkboxes, but it could be done with additional buttons. As for the "no list" option, that could also be done with a separate list - as long as it was fine that that person showed up in the source wikitext for the page. If the goal was to allow users to join an interest in total secret, then it couldn't be done with SMW/SF.

There seems to be two points of coordination here:

1. Following and unfollowing interests (categories) from your user profile and from nodes (formerly "groups").
2. Reflecting the following status in the list of users visible in nodes.

If the list is not updated until the user reloads the page that is fine for now. If the feature is complicated altogether we can start just by allowing users to follow/unfollow from their profiles only.

Thoughts: this follow - unfollow feature is somewhat similar to watch and unwatch a page. The difference is that the list of followers/watchers is public in the page followed. The fact of updating the list remind to the behavior of categories: you add o remove a category on a page (e.g. a User page) and that page appears listed in the category page or not.

We can wait to add the concept of "members" different than followers if that complicates things. If guaranteeing privacy with "no list" is not possible (e.g. appearing in source code would be still bad) then we can skip the feature altogether. People can still watch a page anonymously using the MediaWiki watch feature.

This post was posted by Qgil-WMF, but signed as Qgil.

We have already user profiles, project pages and event pages, but Tasks are new. They are a new entity and we need to figure out the best way to handle them. The natural tasks generators are Bugzilla and Gerrit. We need to find ways to plug them.

This post was posted by Qgil-WMF, but signed as Qgil.

This might be of interest in this context: Mentorship programs/Possible projects#Improve the mediawiki-bugzilla extension to a deployable level, especially if we plan to link bugzilla and gerrit.

fwiw Andre and me used Extension:Bugzilla Reports in previous projects. It did the basic work. I guess Mozilla had a good reason to start another one instead of picking up and improving that one?

This post was posted by Qgil-WMF, but signed as Qgil.

Perhaps they just didn't know about it. You'd need to ask them :)

We need to make sure that users are aware about the information they are putting together visibly in their profiles, in tag based listings and in the admins interface. We are using very extrovert tools like Bugzilla or Gerrit, which allow others to check e.g. your email address. This project won't push the transparency further but might make it more evident.

A potential solution for this is to identify the factors of privacy you want for your data:

1. Visible in profile Y/N.
2. Visible in lists Y/N.
3. Subscribed to notifications Y/N.

Some data WILL be public e.g. tasks assigned. We are doing this already now.

This post was posted by Qgil-WMF, but signed as Qgil.

As it is defined now, this project doesn't have task management with its scope. At least not now. The focus is in attracting new contributors and allowing more effective notifications and connections between old and new contributors. This is complex and disruptive enough, and I prefer to leave the rest for later, or for a separate project.

Once a project, a contributor and an optional mentor get connected through a task we need to a way to follow up, complete and evaluate the task. Different teams are using different tools for this. As said, it is another complicated beast. We discussed a bit of this recently at Volunteer_coordination_and_outreach/Openhatch_2013-02-27.

This post was posted by Qgil-WMF, but signed as Qgil.

Guillom owns in Wikimedia Engineering/Project documentation howto and it would be great to have him as lead for the planning of the new Project pages. Yesterday I pitched the ideas of this project to him and he was excited and willing to help. Guillom is the perfect person to be involved in all areas of this project, but specifically for the Project pages I see him as the champion. Hopefully he will be able to allocate some time on this as well.

This post was posted by Qgil-WMF, but signed as Qgil.

Just a quick note to confirm this. I've expressed my interest for this project, and I hope I'll have the opportunity to work on it.

Extension:SocialProfile is a potential candidate for the improvements in user profiles. Still, it comes with plenty more features than we seem to need now. And the status of current development / maintenance needs to be clearer now. We need to reach out to the developers and main users for feedback.

This post was posted by Qgil-WMF, but signed as Qgil.

I think Semantic Forms (together with Semantic MediaWiki) are a better option for user profiles in this case, since they allow complete control over the set of information users are meant to enter. On that note, I also think they're the best option for storing event, task, group etc. information as well. Then again, I'm biased. :)

The chances of SMW and SF ever getting deployed in production are slim to none, especially seeing as that wikidata has a fairly overlapping set of functionality in its scope. Remember, I say this as a fairly prolific SMW/SF user.

There is no perfect solution here and now, but we need to find the best feasible option.

Yes, the aim is to use tools that one day we can move to production in Wikimedia servers but if those tools don't exist today, what should we do? For instant, the Global Profle project might be a solution for this problem one day, but that day is far from now: the project is inactive and afaik nobody has it in current plans.

Wikitech is not in a regular production server and has already SMW software installed. Is Semantic Forms an option to consider? Are there better candidates we can use now?

This post was posted by Qgil-WMF, but signed as Qgil.

Sorry to dismiss that solution so quickly. SemanticForms is already installed on wikitech. We can use it as a proof on concept for what we eventually want, then when there's a long-term solution in production, we can switch this in wikitech as well.

Agreed. SemanticForms looks like the right way to go, even if only as a temporary tool until something like GlobalProfile is eventually built.

In WikiVote we have previously used Social Profile but have found it very restrictive. We have replaced it with Semantic Forms + Semantic Signup because those allows us to flexibly set up the profile fields, enables 'people search' and queries and has more attractive code structure. I don't think that Social Profile is the right way, the extension tries to do too much things at the same time, and does it in a fixed and rigid manner.

Yes, Semantic Forms seems to be the way to go.

I'm not sure about Semantic Signup for our case. An invitation to fill your profile should suffice. New users of Wikitech have to deal already with a Gerrit account creation when signing up and all the rest of fields described in the proposal are optional. Plus we have all the current users with accounts created. I imagine people adding more data (e.g. interests) over time. In fact the workflow for that might not even start in their own profiles but e.g. landing in a Group page and signing up for it.

This post was posted by Qgil-WMF, but signed as Qgil.

Agreed.