Talk:Product development/Flow

Previous page history was archived for backup purposes at Talk:Product development/LQT Archive 1 on 2015-07-10.

(Pasted from previous discussion page)

Hey, since there are some "how do we do this" notes... Why not match these volunteers or interns with actual product managers at the Wikimedia Foundation? Product management is not a common role in FOSS communities or in general, and throwing random volunteers at such a little-known and largely misunderstood profession seems like a recipe for disaster. If we're being honest, Platform and Ops are a really dangerous territory to bring in completely inexperienced product managers who may be flaky or poison the well. These departments have generally never had PMs, and our value is unsurprisingly little understood in those areas of Wikimedia/MediaWiki engineering. Steven Walling (WMF) • talk 01:10, 28 February 2013 (UTC)

I completely agree with you. However, my understanding is that the primary motivation for setting up a volunteer PM program is that the Product department at the WMF doesn't have enough resources to manage those projects, nor bandwidth to mentor or guide volunteers to do it. I believe a conversation is currently happening at the Tech Director level to clear that up a bit, because there isn't yet a shared understanding among them of the whys and hows. In the meantime, what I'm focusing on is a lightweight system where the activities in need of PM resources consistently provide a list of clear calls to actions that volunteers can get involved in (for example, prioritizing bug reports or features requests), because it seems like something that can be useful regardless of the outcome of the D-level discussion. Does that make sense? guillom 22:54, 28 February 2013 (UTC)

Product management is a normal role in any team environment - but it is not necessarily a designated one. If needed, someone steps up and starts coordinating the team and stuff happens, but they don't need any fancy title or what have you to do so, they just do it. You only get the designated folks with titles and such when that stops working, or when there are higher ups that don't expect it to work/keep working (and with bigger projects they tend to be right, but many FOSS projects tend to be made up more of little things where such designation, if anything, is as like to get in the way as anything else).

To call out Uncyclopedia as a personal example, we don't have product managers so much as people who will rip your head off if you break certain things, but in the end the effect is about the same. Things inevitably get broken anyway, and that is why we have these folks - so they get fixed. But at the same time, none of us knew what we were doing coming in - we learned because we needed to. We cared for the project and did what was necessary and by the gods it actually worked. And that's the beauty of FOSS - people care, and people learn. These are projects we can sink our teeth into because they matter to us, and nevermind how clueless we are starting starting out, we learn precisely because we can get into it and actually be part of it. -— Isarra ༆ 07:45, 1 March 2013 (UTC)

"...we don't have product managers so much as people who will rip your head off if you break certain things, but in the end the effect is about the same. Things inevitably get broken anyway, and that is why we have these folks - so they get fixed" That's not really what a product manager does. Or at least, it's a lot more than making sure bugs get fixed and functional requirements are met. Anyway, you're right that product management is a role just as much as a job, and lots of teams have those needs met by others informally. That can be perfectly healthy. My concern is more to do with setting up volunteer product managers to fail, and souring developers in Platform/Ops on the idea of product managers altogether. Steven Walling (WMF) • talk 22:02, 1 March 2013 (UTC)

Everybody fails. It's how people learn. Fearing to fail just makes the inevitable failure worse and the learning less useful. If the folks want to work with people and want them to learn, general failures won't sour anything - but that does take effective communication to get set up in the first place. Fortunately communication a key skill especially for an official sort of product manager, so that should be no trouble if you help work with them. -— Isarra ༆ 18:12, 3 March 2013 (UTC)

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

Hi I would like to volunteer for the volunteer PM program

volunteer PM program - nutshi@gmail.com

Hi, sorry, this program is not active currently.

The advice to volunteers wanting to join a project links entirely to strategy:Product Whitepaper#Red_link: WikiProject support, which has not been updated for five years, and even then consisted of aspirations for things that might happen in what was then the future (and is now the past).

Is there more up to date advice that can be given to volunteers wanting to join in? After all, that is what we all want, isn't it?

Thank for spotting the rotten links. I have updated that section, pointing potential volunteer PMs to #possible-tech-projects in Phabricator.

The phrases "researching and prioritizing the users' needs" and "deciding and specifying what to build" should probably link to something describing where and how those activities take place.

Has the Wikimedia Foundation consitered releasing a universal Windows platform app to replace the current Wikipedia app for written for Windows 8?

As far as I am aware of there are no plans at the Foundation to develop our own Windows app. You can learn more about current products, plans, and the team behind them at Wikimedia Apps.

Unfortunately there is no option to set a preview picture for the Wikipedia-app search (e.g. a human in full size in in the app-preview cropped -> only the abdomen is shown). I would like it, if there exist such an option.

Wiki should develop picture recognizing feature.It is the other form of translation that involving pattern recognition in which will give a final information to users.Users just places (uploading) a picture,and wiki translate this picture to give a necessary information.It sounds to be a complex project,but worthy to be given an effort.

@Ron joe see related T120759. Automatic recognition is a complex feature indeed. You might want to check or continue this discussion at Multimedia.

Yes.Users give some keywords concerning an aspect they want to get information from that picture.So,the searching could be focused on that picture's aspect.

It could be extended to be an answering machine to give information to users concerning their intended question.

Given that even organisations as impressive, powerful and vast as Google are only barely able to provide an API to do this, and one which is not as I speak good enough for unattended use for the quality we'd expect for Wikimedia, I don't think this will happen for us for a decade or so, sorry.

Newcomers interested in this page will have a hard time finding how who to ask a first question. Can we have a list of contacts here, even in the form of a nice gallery of people? It is a lot more welcoming when you find something like this.

There is a link to Wikimedia Product Development, a stub that links to Staff and contractors at the WMF site. There are links to tech-ambassadors (not the right place for this), the list of maintainers and the list of projects (both implying that you have already a good idea of what are you after).

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

Listing contacts doesn't necessary help, though - it's just this ominous list of folks who are all high up and scary. Even if they're not actually that high up and scary, though, how's a newcomer to tell which would even be around or respond, or would be best to go to for a particular issue?

Where's the central plaza to just dump a 'hi I have a question blah blah blah...' where everyone can see it? Less confusing, less daunting, less pressure on any one person to worry about it, and more likely to reach the actually relevant ones. I do hope we don't have to wait for Flow for this.

We need a low entry barrier and no matter how small a full project is, it is going to imply a significant amount of work and trust in order to work out. Prospective product managers could be directed to Bugzilla, where we have thousands of enhancement requests waiting for someone to take action on them (and not only enhancement requests: product managers also need to have a sense about current issues and how to prioritize them). We also have pretty decent documentation about Bug management that is mostly useful for someone going through enhancement requests.

Once someone has done some exercise in our Bugzilla then everybody will have a better grasp of the tasks to do next. Also getting CCed in 40 reports you just shuffled is a good way to meet people and stick around...

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

Directing people around to various random places won't help in the slightest if they don't actually do anything. Hells, even doing stuff won't help if they don't talk to others, and one can get a whole slew of bugzilla mail without it meaning squat if they never get the opportunity to actually work with - and communicate with - other users on actual bugs.

People don't stick around because they've done little things and run into others, they stick around because they've helped and been helped and made a real human connection. People stick around because they can see the difference they've made, and that requires recognition. Documentation and automated tools don't get people recognition, but working directly with others very often does.

Sure but... how do most people start editing Wikipedia, fixing a typo and adding a couple of lines in a paragraph or getting a view of a whole category to assess the quality of the pages in it?

I'm just looking for the simplest tasks a potential volunteer PM can start doing on their own, as a gateway to more complex responsibilities. Currently the simplest tasks described in this page are still pretty complex for a newcomer (and many of us).

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

Product development is not editing Wikipedia. Someone seeking to be a product manager will need to get to know the people, the situation, the code, and everything else in between; fixing typos on a content project is not even remotely analogous to that.

My point is that such simple tasks do not address the situation - they would be useful to get done, but they are not a gateway because tasks are not a gateway here, people are. Tasks are secondary.

It doesn't matter what a volunteering activity is about: it is easier to ge more and more diverse people when there is a progression of steps from simplest to more complex. If someone feels like jumping to the more complex from the beginning that is all good, bt we need to have something for those having one evening and willing to try.

Another general rule of distributed volunteering projects: it is better when there is a pile of non-critical little tasks that someone can start and complete, leaving an improvement even if that person walks away the next day. The simplest PM tasks that we are listing not only require significant work to get you started, they also require a nice dose of work before you can improve the current situation and leave.

In other words: I'm not arguing against anything currently proposed at the page, neither with any of your arguments in this thread. I'm only saying that there is more we can do to connect casual volunteers with a first task that would lead them to other tasks.

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

Well, for what's on this page, steps that don't go anywhere relevant to this won't help this any. There may be some parallel here to how universities and other bureaucratic entities add tedium to head people off unwanted paths, except wikis and such tend to just add bureaucracy and tedium... just because? I'm not really sure why, really.

Some numbers and links: 78 enhancement requests (vs 23 bugs) are unanswered after 2 years or more. If you count 18 months or more the numbers are 331 requests vs 136 bugs.

Volunteer product managers could start learning and getting their hands dirty while going by picking a first feature request from this list. We could have very simple instructions including to CC volunteer PM mentors like you and me) so we can observe and help them getting through. After a few semi-random requests probably they will start having a better idea of a project to focus, some experience accumulated in our community and a couple of colleagues nearby.

We could also attempt to have a Feature triage day/week just like we organize the bug triage activities.

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

So if they're picking features, what are they supposed to do with them? Staff don't tend to answer well to volunteers in my experience, and volunteers can be pretty damn unreliable at times given their own schedules and priorities.

At that point all that remains seems to be doing it themselves... it's the only sure bet, really, assuming there's a chance of the fix/implementation actually getting merged.

Even before picking a feature: triaging is good training to get you started. It's a useful way to learn more about projects, contributors and do useful work.

Once you find an interesting enhancement request you can blow the dust off, CC other contributors that may help assessing it and start converting it in a plan.

If we send them to MediaWiki core first then yes, the chances of finding problems finding developers, discussing the new feature, eventually merge it etc are higher. But this is only one product of many. And arguably most of the enhancement requests are either small suggestions that maybe were overseen or forgotten, or features that can be implemented via extensions or gadgets.

On the other hand: what do you propose to do?

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

Wherever folks go there's danger and even likelihood of not getting enough others engaged to really do anything, though. Blow off the dust and you're doing good to even get a 'sure, whatever'. I guess the whole product manager thing just seems like yet another layer of bureaucracy to me, that on top of everything else would only slow down folks working on already limited spare time.

So all in all I'd say we're all doomed. Doomed. Doooomed.

Yeah, I have nothing productive to add.

(Pasted from previous Discussion page)

Below are some (relatively raw) notes consolidated from various discussions:

• The goal is to facilitate involvement and provide opportunities for participation with direct calls to action, possibly using a list of tasks or microtasks.
• The tasks will initially be Product development-focused, but the system will probably be extended to all kinds of activities (as on How to contribute)
• What system do we use for this?
  1. LST from Product development: All the todo items reside on Product development and are marked with LST so that they can be transcluded into activity pages (the same way the Project:Calendar works)

     Contrary to the Project:Calendar, we won't be transcluding tasks from a lot of different pages, so there isn't a big need for centralization. Besides, many teams use different and inconsistent tools to manage tasks & backlogs, so it doesn't make much sense to build a system too complex (e.g. being able to summon todo items by project, activity type, etc.)

  2. Subpages: Some projects use a /Todo subpages to list their upcoming tasks, like Parsoid/Todo. We could generalize that system to all activities.

     Maintaining a /Todo subpage for each activity increases the maintenance cost of activity pages and isn't needed for many projects

  3. LST from activity pages: [current choice] Each activity contains a "Get involved" section marked with LST so it can be transcluded into Product development if so desired. A template can be used to provide a common appearance for those sections and to integrate a tracking category.
• The "Get involved" section will include links to specific queries in bugzilla, RT, etc. and possibly links to other todo/task/backlog management tools used by engineers, like Trello or mingle. The goal isn't to replace existing workflows that already work for engineering teams, but to make sure that we consistently provide points of entry for contribution.
• We'll start with Platform & Ops projects, because that's where Product Management resources are most lacking currently. Ideally, the system will be extended to all activities in the future.

guillom 23:44, 27 February 2013 (UTC)

So, it turns out that we can't use LST from activity pages, because the whole activity page system relies on selective transclusion of the infobox's content. Hopefully, once/if we move them to wikitech and use semantic fields, we'll be able to get rid of this ingenious but super hacky system. In the meantime, I'm not going to transclude the tasks themselves, but link to the proper section for each activity. guillom 17:05, 18 March 2013 (UTC)

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

If plain old wikitext isn't good enough for this talk page, perhaps we should be using Flow?

I'm fine with switching to wikitext.

Flow will be on this page soon, following the Flow/LQT conversion process (they're working on one newly reported bug, before continuing with the item listed as "day 10", which will include this page). HTH.