Talk:Technical Collaboration Guidance/Vision/W

Comments

Boats on rivers

This analogy is not about collaboration, but about gatekeeping: I can't get on a boat from a bridge, let alone change how the boat is designed or built or decorated. Also, bridges are not usually meant to regulate river circulation: what you describe is a lock, not a bridge. Nemo 20:00, 25 May 2016 (UTC)

This essay focuses on the collaboration between development teams and communities (wiki projects) as collective entities. These communities have hundreds, thousands of members each, and the majority of them might have opinions about boats but won't be willing or capable to jump in a boat and manipulate it themselves. Your scenario is about individual contributors volunteering directly in projects, which is a very important use case that the Technical Collaboration Guideline should address indeed. Collaboration with communities and collaboration with individual contributors cannot be addressed in the same way efficiently. The free software movement has many references about open collaboration between individuals in projects, but there are less references that can be directly applied to the very special situation of Wikimedia. This is why this essay focus on the latter.

Living in a region with many rivers, bridges, and locks, I still think that bridges are a better reference here. This is a guideline that aims to cover projects of all sizes and characteristics. Not all boats are expected to stop in every stage, and in fact none of them is required to stop. The analogy of this guideline indicates that if you skip checkpoints in the bridges you have a higher risk of finding surprises and being out of sync with communities as you approach the deployment phase.--Qgil-WMF (talk) 12:22, 26 May 2016 (UTC)

Is the analogy really necessary? Analogies are most often used to explain extremely complicated things to people who are unlikely to understand the complexities staright away, such as quantum physics to schoolchildren. Is technical collaboration between paid staff and a volunteer community really so difficult to describe? Or is it believed that one or other group is unlikely to understand the concept without intellectual support, and if so, which? A disadvantage of analogies is that discussion inevitably turns to the exactness or otherwise of the analogy rather than to the thing under discussion. Rogol Domedonfors (talk) 06:37, 2 June 2016 (UTC)

Before writing them down, I have pitched the ideas of this essay to several people (WMF colleagues, volunteers, chapter people) for a long time, in casual meetings and conversations. I remember mentioning the image of a river for the first time last January. I evolved the analogy progressively, because it seemed to be useful for many people to get what I meant in simple, broad terms. Some people know about communities processes but less so about software development processes, and vice versa. Some people are very familiar about both, but they are a minority, and this analogy doesn't aim to stand an accuracy crash test from them. I think now we are here discussing this essay because we have just started with the actual recommendations. As the Technical Collaboration Guideline materialises and becomes a reference, I expect this essay and its analogy to become less relevant or completely irrelevant, having fulfilled its goal.--Qgil-WMF (talk) 09:47, 2 June 2016 (UTC)

So it seems you do think that this process is so difficult that most people can only understand it via analogy. I have a more optimistic view of the volunteer community. Rogol Domedonfors (talk) 12:11, 5 June 2016 (UTC)

Silent majority

How does "silent majority" fit in the analogy? Is it a navigation term I missed? Nemo 20:02, 25 May 2016 (UTC)

This essay doesn't pose any creative competition to Aesop's Fables, indeed. If you don't understand what "silent majority" means in this essay, I can explain. If it's a matter of style, I welcome suggestions or we can move on.--Qgil-WMF (talk) 12:26, 26 May 2016 (UTC)

It's not a matter of style, I think the "silent majority" stop should just be removed. The boat should only sail towards destinations where it's welcome. Unprofitable visits are not something a boat should do. Nemo 13:22, 26 May 2016 (UTC)

Wikimedia has hundreds of projects and the big majority of them receive most new features without organizing any community discussion. What happens now is that those projects get the new features deployed whenever the development team and Release Engineering deploy them, and this system seems to be working well. In the context of this essay, when a project asks whether any projects have explicit opinions about getting a feature earlier or later, the communities that don't respond are that silent majority.--Qgil-WMF (talk) 08:35, 31 May 2016 (UTC)

Serious matters

"Blocking a project is a serious matter". This sentence should be balanced by an earlier sentence acknowledging that starting a project is a much more serious matter. The first day is the most important day for a boat, while stopovers are routine. Nemo 20:06, 25 May 2016 (UTC)

 Done Good idea, thank you. Technical_Collaboration_Guideline/Vision#Starting_a_project.--Qgil-WMF (talk) 13:17, 26 May 2016 (UTC)

Thanks, looks better. Nemo 13:32, 26 May 2016 (UTC)

Project information

This is the most important section in my opinion, everything else is disputable. The basic information should be expanded, for instance most project ideas are doomed from the beginning because they lack a problem statement, goals and/or an overview of past discussions, ideas and approaches to the matter. Nemo 20:10, 25 May 2016 (UTC)

I agree on the importance of project information. I have been checking the current drafts and open tasks, and this problem is more often assumed or spread in different places than centrally addressed. It looks like phab:T121500 is the best starting point. We could polish that task to address the points raised here. We are discussing about making this task a quarterly goal for our team.--Qgil-WMF (talk) 09:30, 2 June 2016 (UTC)

Initiating projects

The description here suggests rather strongly that projects are initiated by WMF. There is no discussion about how the various communities come together to discuss what is needed and what broad framework it should fit in before starting the design and build phases. But this is precisely where projects have come unstuck in the past. Rogol Domedonfors (talk) 06:30, 2 June 2016 (UTC)

Isn't this sufficiently addressed in Technical_Collaboration_Guideline/Vision#Starting_a_project, a section that I added after Nemo's feedback at #Serious matters?--Qgil-WMF (talk) 09:33, 2 June 2016 (UTC)

No. The analogy suggests that the communities are passive consumers. If it is indeed your view, as it is mine, that the communities (contributors, readers, etc.) will be an integral part of the early requirements capture and design specification, then it can do no harm to say so clearly and explicitly. Come to think of it, if you hold a different view then it probably should be articulated clearly as well. Rogol Domedonfors (talk) 16:07, 3 June 2016 (UTC)

Lessons from the past

The description is rather anaemic without some examples. Obviously we can't take examples of successful projects from the future, but what about the past? Some illustrations of what went well or badly to illustrate each phase would be instructive. The lessons-learned exercises from some of the more painful episodes fom the past would be a valuable source of examples here. Rogol Domedonfors (talk) 06:34, 2 June 2016 (UTC)

I agree that adding examples and lessons learned would be very useful, but I wonder whether we should focus on doing it in the actual Technical Collaboration Guideline, as a complement to the recommendations made there. The goal of this essay is to serve as inspiration to the actual work, and I think this goal is basically fulfilled. I'd rather invest further efforts writing the actual recommendations and complementing them with examples, howto's, etc. Keegan (WMF), what do you think?--Qgil-WMF (talk) 09:38, 2 June 2016 (UTC)