Talk:Technical Collaboration Guidance/Private planning

Examples

User:Whatamidoing (WMF)'s examples from T123611

1. Reason: Draft in private if you truly don't know what you're talking about yet. "Something or another about, I dunno, it should just be easier for people to find stuff" isn't a very useful entry point for collaboration. Post when you're past the point of doodling in the margins of your notes and can explain what you're thinking about in reasonably concrete terms.

   Comment: This might not be a very good reason. Drafting in public for this reason gives the opportunity for others to contribute to you learning about the topic, and perhaps finding some understanding and concept along the way. Keegan (WMF) (talk) 19:04, 9 February 2016 (UTC)

2. Reason: Draft in private when your idea changes every day, or every hour. Post when you've stuck with the same iteration for a week.

   Comment: Wikis are meant to be updated as often as needed, with relative ease. That's one of the points of using a wiki. Keegan (WMF) (talk) 19:04, 9 February 2016 (UTC)

3. Reason: Draft in private when you don't want help. Post when you do.

   Comment: You want help :) We work in a collaborative environment. Keegan (WMF) (talk) 19:04, 9 February 2016 (UTC)

4. Reason: Draft in private if you're talking about real people. Post after you've turned "WhatamIdoing is incredibly annoying and stubborn" into something like "She's tenacious and passionate about her community".

   Comment: Is your product plan really concerned around one individual or set of individuals? Who is your actual audience? If it is not the people you are concerned with, you should be writing in public to your audience anyway. If your product plan is concerned with one individual or set of individuals, you should be working with them in private or public directly to resolve issues so that planning can be done in public. Keegan (WMF) (talk) 19:04, 9 February 2016 (UTC)

5. Reason: Draft in private when you have an idea that needs careful thought. Post after you've determined things like whether Legal will break out in a bad rash, or when you have a reasonably clear explanation of how your potentially good idea differs from a closely related bad idea (or whatever else prompts the need for careful thought).

   Comment: This is a good reason. Keegan (WMF) (talk) 19:04, 9 February 2016 (UTC)

6. Reason: Consider drafting in private when you know that an idea will be popular with core community members, but you're not sure that it's feasible. Post when there's a chance that it could really happen. Nobody likes to have longed-for treats dangled in front of them, only to have them snatched away with "Ha ha, only kidding! It turns out that this isn't feasible after all!"

   Comment: Consider planning in public, but in a very targeted way to engage those that only really want to be involved for the long term, and bring in others for the potentially important decisions. Keegan (WMF) (talk) 19:04, 9 February 2016 (UTC)

This is the third attempt at publishing my thoughts here. I kind of realized I'd better leave aside more strategic issues and just list some of the concerns I have. The TL;DR is that there is a moment for personal musing, and a moment to share with others. BTW, there are also several degrees of "others", between yourself and the rest of the universe (and I can't believe we need such reminders, but heh). It seems to me that an idea and a plan are quite different things, and that what's described above seems to come before the Understand phase.

Making everything "collaborative" is likely to produce fewer "out of the box", independent, different approaches, bringing others' biases early in the game (in good faith, sure).

Assuming that the scenario is "I have some kind of problem which is looking for some kind of solution", not having at least a personal understanding of such problem/not knowing what you'd want to do means you're making it trivial for others to easily convince your their solution is better or to try to micromanage you in how anything should be implemented.

It also means some will feel free to skip the "RTFM/do proper research phase", as you'll rely on others to provide you a TL;DR of what you oughta know - and you shouldn't, because you should see with your eyes and carefully considerate the amazing work that certainly someone else has done before on the subject.

Both as a volunteer and as a staff person, I want to underline that everyone's time (including yours), good will, trust and historical knowledge are not infinite, and should be used considerately as you're not the only one requesting them.

You don't really need the eyes of an entire movement on something which is bound to change often, and even dramatically, before it gets to the stage where the Understand phase can happen.

You don't want to create unnecessary drama, and related negative attention, especially since I doubt you'll be the one committing to addressing and incorporating feedback personally (as an example).

Most importantly, I don't want you to become convinced that "dreaming big" is not possible in our environment just because those kind of ideas might get shot early. Aim high and compromise later. --Elitre (WMF) (talk) 17:47, 24 February 2016 (UTC)

Why do you think that "dreaming big" is unpopular? ChristianKl (talk) 10:56, 29 October 2016 (UTC)

Meeting notes

• User:Trizek (WMF): Community Liaison, Flow/VisualEditor - https://etherpad.wikimedia.org/p/PDP-PrivatePlanning-Trizek
• User:Quiddity (WMF): Community Liaison, Flow - https://etherpad.wikimedia.org/p/PDP-PrivatePlanning-Quiddity
• User:Aaharoni-WMF: Product Manager, Language Engineering - https://etherpad.wikimedia.org/p/PDP-PrivatePlanning-Aaharoni
• User:CKoerner (WMF): Community Liaison, Discovery - https://etherpad.wikimedia.org/p/PDP-PrivatePlanning-CKoerner
• User:Rdicerb (WMF): Director, Community Liaisons - https://etherpad.wikimedia.org/p/PDP-PrivatePlanning-Rdicerb
• User:DannyH (WMF): Product Manager, Community Tech - https://etherpad.wikimedia.org/p/PDP-PrivatePlanning-DannyH

Google Docs

Google Docs are a nightmare for knowledge management: they can't be organised in any way, they aren't meaningfully linked, they are impossible to archive and they will eventually disappear (e.g. when the people's WMF accounts get deleted). It's imperative that any Google Doc which gets created is also archived in some form (OpenDocument or at least PDF) on some wiki. Nemo 17:56, 30 August 2016 (UTC)

Just a point of process (I don't disagree that they are a nightmare!): When a staff member leaves the foundation any gdocs that they 'own' are inherited into their manager's google drive. The same sharing settings are kept, in fact (I just looked). It just says "$somedoc by deleted user" instead of their name at the top. I presume when a manager leaves their docs, including their past employees, go to their manager (I can't test this myself). I don't know what happens to documents of EDs, however. Greg (WMF) (talk) 18:12, 30 August 2016 (UTC)

Phabriactor

Not everything has to be written down in a Wiki. Phabricator is also a useful venue for many smaller technical ideas. ChristianKl (talk) 10:46, 29 October 2016 (UTC)