Answer History
Event Timeline
But this is the exact reason I started to consider Ponder in the first place. All previous attempts implied fragmentation, while Ponder is integrated in the system people already use (Phabricator), both developers and volunteers, and in numbers. I've explained in more details how I see the current situation at https://meta.wikimedia.org/wiki/User_talk:SDeckelmann-WMF#How_volunteer_developer_support_could_be_improved_in_Wikimedia. Please share your view if you'd like. You can also join the discussion in the English Wikimedia Discord I started here.
Note that it's not that we have very many successful standards that we need to choose between. The way I see it, all existing platforms fail in a major way (first of all – because all of them are kind of not intended for what we're trying to use them for!), and there is a reason why their use is severely limited. We can't solve this problem just by agitating people to use them or consolidate around them; there is a serious flaw in these systems themselves. As I said in the topic I linked,
I don't consider the current means outlined at mw:Communication, including IRC, mailing lists and Discord servers, sufficient and/or convenient.
In this question, I'd like to hear perspectives on whether Ponder is good to overcome both the fragmentation and unsuitability for our purposes, based on the functionality it offers. If it's not, maybe something can be done about it (see the question details)?
I think ponder is sort of a minimal viable product state currently. It lacks some features like putting questions on workboards and there just aren't many
(or any?) integrations with the rest of Phorge. That wouldn't take much effort to improve it, most likely.
One nice thing, for Wikimedia's purposes, is that ponder questions would show up in the same search results along with maniphest tasks. The search experience is pretty nice on Phorge in general
@20after4 Thanks for the response. Integration with search is something I overlooked, but you're right; tasks can naturally come from questions, and questions can naturally come from tasks. Their joint discoverability and interplay is a fertile soil for education and development. As volunteers, our role is kind of limited in many cases to being passive recipients of what is decided in WMF internal communications. Having public discussions of components could add more dynamism to the process.
That wouldn't take much effort to improve it, most likely.
Glad to hear that assessment! Yup, Ponder feels raw; I can't quote your comment and don't get an autopreview. Seems to have basic functionality only, but quick-to-catch-up?
Well, if you take, say, GitHub's discussion feature (example), it reminds me of the Discourse board actually, and I bet taking things to that level of detail would take time. But an aspect that I consider to be of utmost importance is that people should be able to track subjects (=components) they are interested in and/or have expertise in. This feature alone would immediately raise the level of integration from
- "There is some unstructured stream of communication that you'd have to intensively fish in to pick out what is relevant to you,
- and your input will quite likely be quickly buried forever under other texts and have only a limited, short-living impact"
to
- "You have a neat inbox tray that gets populated with presumably-relevant, concise titles that you can act on,
- and whatever you articulate will make a difference and have a reach".
Part of the argumentation is based on a wrong assumption as Wikimedia Phabricator is not "used in numbers". Please compare the number of Wikimedia wiki editors and Wikimedia Phabricator users (minus some developers only). There are still many on-wiki folks who are uncomfortable using Wikimedia Phabricator.
But what is the alternative, on-wiki discussions? Does this actually work or can it? E.g. I have a question about a class of OOUI. Where do I go?
- Talk page that discusses that specific class (e.g. https://www.mediawiki.org/wiki/Talk:OOUI/Windows/Process_Dialogs)?
- Main talk page of OOUI?
- Extension talk page?
- Some things also have pages on local wikis (and, as a discussant on such a wiki, you often have to say to people "Hey, this is not discussed here, the devs responsible don't visit this page").
And how probable it is that right people will come across that topic? Especially if the question is esoteric and only few people know how the component works. The devs who write them are often more known by their Gerrit/Phabricator handles, not wiki accounts.
And if we take a component like VisualEditor, question from endusers ("How to do that thing I need as an editor?") are often mixed with questions from developers. So it's not surprising that these pages are sparsely populated by devs. The signal-to-noise ratio is too low.
In general, as long as we talk about technical community outreach (which includes volunteers that contribute to e.g. MediaWiki), I don't see anything extreme in asking them to create a Phabricator account. Most already have. Bug reports on wikis get a "tracked on Phabricator" tag. From my past experience as a contributor to ruwiki technical forum, even when non-technical people reported bugs, they would often register on Phabricator and file a task. Phabricator is not Gerrit (or even IRC). Sometimes they don't create a task, but subscribe to one to receive updates.
The answer to "What's the alternative?" comes at the end of a long process
(Right, but I'm responding to your opinion which also comes before the end of that process, and this question is supposed to be a part of the information-gathering phase of that long process which you're kind of deflecting even though I value your perspective.)
I think this would need a huge huge discussion across Wikimedia communities which nobody has the capacity to plan and lead (my personal interpretation) in order to get to a rough concensus.
I'm also not sure you correctly interpret the premise, because what I fancy is quite limited in scope: it's supposed to be a (pretty organic IMO) development of what already exists on Phabricator and not part of some kind of great migration of Wikimedia communities to Phabricator to discuss technical issues. (Again, I can't even say confidently that there is something to migrate – questions that are of relevance to developers as opposed to end users are hardly even discussed on wikis.)
I agree though that what was planned as limited in scope could grow out of it, so this should be agreed upon in advance.
Alright, more questions arise as we discuss this in increasing detail, so I guess we should continue at an appropriate platform once and if this moves forward.
@Jack_who_built_the_house This is one of the things that always frustrated me with Wikimedia projects, there is a tendency to discourage doing something new or trying something experimental. Instead of just putting it out there and letting it either succeed or fail based on the merits, there is a lot of bureaucracy around consensus building. Sadly it's just the way things are with a community/organization as large and as socialistic as Wikimedia has become.
@aklapper knows this subject better than anyone and has earned my respect 100x over, however, don't be too discouraged or take too negatively the feedback that @aklapper has offered.
I do think that Ponder is seriously lacking in polish. It would need some attention to features and usability before it could be a good fit for Wikimedia's needs.
(Ponder does not allow me to add a comment as I have already answered this question. So I keep editing my single answer, which feels wrong...)
That's an example of one usability problem that should be fixed, really..
As much as I hate to say this, stackoverflow may be the best alternative right now.
BTW, check this out, WMF's Developer Satisfaction Survey is just out; there is a section on Phabricator there, and we see some evidence very much supporting the hypotheses I outlined:
- Almost everybody uses Phabricator: {F2157279}
- Shared space for staff and volunteers is what people value in Phabricator: {F2157280}
Time to build on these premises!
Instead of just putting it out there and letting it either succeed or fail based on the merits, there is a lot of bureaucracy around consensus building. Sadly it's just the way things are with a community/organization as large and as socialistic as Wikimedia has become.
I can relate to that. We can hardly change the social structure, but we can change the technical side. This is why I made Convenient Discussions, which contributed to speeding up processes in the communities where it was used. No more pain of meticulously editing wikitext to participate in discussions. Wikipedia has "wiki" in its name meaning "fast" in Hawaiian.
Mailing lists, IRC are old ways; they are too cumbersome and awkward for our purposes. I have a really hard time with them, and I know people who share my pain. They are no wiki way. We should aim to make developing MediaWiki and open source bring joy, not suffering. A usable Q&A system is a major step in that direction.