Wikidata talk:Contact the development team/Process review 2020

The first feedback round is now closed, but you can of course leave comments on this page.

About the channels (comment by Jura1)

From a community perspective, I think there isn't much benefit of such requests and comments made offsite (Facebook, Telegram, onsite, email, etc.). Even random talk pages on mediawiki.org are problematic.

Supposedly phab could be a tool for this, but it seems primarily geared towards and understood by MediaWiki developers for handling their priorities. Even if a contributor goes through the troubles of making a trivial request there it's likely to be ignored or not properly followed up (e.g. phab:T254968). Tickets can't really be searched easily. Flow talk pages sometimes used on mediawiki.org or even wikidata.org have the same defect.

Maybe more effort should be made to direct users towards Wikidata:Contact_the_development_team and its subpage. --- Jura 16:31, 10 September 2020 (UTC)

• I agree that the community benefits from interactions happen on Wikidata. I don't think it's too much to ask from a person who reuses Wikidata to learn how to use a Wiki to engage with the community through the Wiki. Community works well when it's possible to build community consensus. That can happen on Wikidata but not on social media.

There might be some Wikibase users that are not part of the Wikidata community that can reasonable communicate outside of Wikidata but for the core of Wikidata, the Wiki should be primary. ChristianKl ❪✉❫ 11:50, 16 September 2020 (UTC)

Note to readers. The task mentioned above was closed as resolved 15/9-2020--So9q (talk) 11:51, 23 January 2021 (UTC)

Content flow

We miss some requests because they are posted on channels that we do not monitor or where they disappear because of the huge content flow (e.g. Project Chat, Twitter)

How much hours per week do you believe it would take to read the project chat? ChristianKl ❪✉❫ 11:29, 16 September 2020 (UTC)

Community involvement in roadmap

From my perspective the fact that the roadmap is made without community input is a huge problem. I could imagine half of the development capacity to be driven by WMDE's consideration and half by the community preferences. Community voting the way the Wishlist is handled could be a good way to get an idea of which changes are important for a lot of people and which are of lesser importance. ChristianKl ❪✉❫ 11:55, 16 September 2020 (UTC)

• I think the community was asked for input .. personally, I just find it hard to read (maybe I should take more time to do that). Maybe it mainly provides guidance on how to fit multi-year development in a one year period. Given the usual pace of development, its deliverables are sometimes a bit vague, at least for non-IT people. Many things are obviously needed that aren't directly visible to the Wikidata contributor or user. Once in a while new features emerge and its awesomeness materalizes for the general public (like me). --- Jura 12:11, 16 September 2020 (UTC)

Abián's answer

I understand that some questions are asking for one representative example. However, I've opened many tasks on Phabricator with the Wikidata tag (about 140) and none of these tasks seems to me more representative than the others, so I think I should answer them in a more general way.

Most of the time (2) I use Phabricator. I find (3) no problems in doing so but, once the situation is reported, I (4) never know if the team is going to read the task at some point, and in some cases where I know that the tasks were read (because there was a subscription, comment or other action on them), these tasks were forgotten and lost in the ocean of unaddressed tasks for years, with the same practical result as if they had never been created. To answer the question, (5) unfortunately I don't perceive that the management of the tasks is adequate and my satisfaction is relatively low, 2.5/5. Below I will (6) list the two situations that I find most worrying together with general suggestions for improvement (8). The order is arbitrary.

• Lack of confirmation of reading, understanding and decision. Sometimes I ping the team to let them know about a certain task, but I don't do it to ask for the task to be solved as soon as possible, not even because I think it's an important task; I do it to make sure that someone knows that the task exists. Many tasks I opened over the years weren't read until I pinged the team, and today I still don't know if certain tasks I opened years ago were read at some point or not. It would be useful to have at least a reading confirmation for all tasks and, when possible, information on whether they have a real chance of being addressed. I understand that, with the latter, some users may be offended (probably not me), but I still find it more honest and practical for everyone than to say nothing and leave the task open indefinitely, accumulating and hiding other tasks that do have a chance of being tackled at some point.
• Lack of continuous improvement. Certain designs (e.g. Item pages), extensions (e.g. lexicographical data), data types (e.g. dates, with problems of precision management that generate misinformation), special pages (e.g. Special:NewItem, with only a language code and three free text fields unchanged since 2015, the last one for a list of pipe-separated values), software artefacts in general, even processes, are considered de facto closed or finished at a certain point, sometimes being the minimum viable product, and from then on most suggestions for fixes and improvements on them are ignored. This situation may be intentional or accidental but, in any case, it goes against the agile philosophy as I understand it, and in my opinion it's detrimental to Wikidata. I think that no artefact or process should be free from continuous improvement and that a better balance is needed even if this means devoting fewer resources to new projects or to purely technical improvements. The ideal would be a proactive strategy, with the team regularly thinking about how to improve each of the existing Wikidata artefacts at the user level, and improving them accordingly, so that not many years go by without reviewing and improving any feature or design at the user level. If this approach isn't realistic, I understand that a reactive strategy is applied, with the team waiting for user requests to make some of the suggested improvements and additions. But what is negative for the project and probably discouraging for users who leave their suggestions is not doing either, and I'm convinced that the current ocean of unresolved tasks around certain areas is a symptom of this lack of continuous improvement.

(9) It can also be said that reporting problems or making suggestions is quite easy, and aspects that some users may not do well, such as including the right task tags, can be addressed by other users in a totally open way. In general I agree with the seven points on Wikidata:Contact the development team/Process review 2020#Things_we_would_like_to_keep.

Thank you for taking our views into account. :-) --abián 21:24, 22 September 2020 (UTC)

Hello @Abián:, thanks a lot for your detailed answer that brought a lot of interesting insights :) I wanted to follow up specifically on one point: lack of confirmation of reading.

Do you feel like it would be valuable for you/the requesters if the development team would add a confirmation to acknowledge that we read a message? (this could be for example a short comment or a template "read", "thanks for your message, we will provide an answer as soon as possible", etc.). Would it bring something to the requester? Or should we rather wait until we have a more useful piece of information to contribute (for example a Phabricator ticket, a clear information about whether or not we will take care of the issue, a deadline, etc.)

Thanks, Lea Lacroix (WMDE) (talk) 10:13, 9 November 2020 (UTC)

Hi, Léa! Yes, I think a message like that would be very useful and that the perfect time to publish it would be once:

• someone on the team has read and understood (the understanding part seems relevant to me) the Phabricator task (or, by other means, the message); and
• the task has been considered valid because it describes an actual wrong behavior (or a suggestion that hasn't been implemented yet) and it would be inside the power of the Wikidata development team to resolve the task, regardless of its priority (which could be decided later or even never).

I think this would be the point at which the users can be informed that they no longer need to take any further action with the task if they don't want to, that they have done well all they had to do with that task and the rest of the work is already up to the Wikidata development team. This ensures that, if the task isn't addressed soon (which is likely). :-) it's not because it hasn't been detected, something that can happen, for example, if the Phabricator tag/component/umbrella you're tracking isn't included in a task, or if people on the team forget to check certain tasks because they were busy with other things at that time. If the task isn't addressed later, it will be because of its low priority, the lack of time of the team or other circumstances that the user won't be able to solve (and which I believe can be left to the discretion of the team if you want), not because of someone's fault. In these cases I think it would be enough with a template as you suggest; if the Phabricator task isn't valid, it should probably be closed or assigned to another team; and, if the task/message hasn't been understood, clarification could be requested before, again, replying with the template, closing the task or assigning it to another team. These messages would be useful not only to the creators of the tasks, but also to other users, including the development team; in case of doubt, no one would need to repeat these quick checks because, whenever they were done, there would be a record.

Further updates with the additional information you mention ("whether or not we will take care of the issue, a deadline") would be ideal, but I don't know to what extent it would be feasible to decide and provide that information. In any case, I think what I'm commenting on in this message would already be an important and helpful first step.

I'm glad you are involved in this process, I think it can improve the work of both the volunteers and the development team, and therefore can improve Wikidata in general. Thank you and congratulations. --abián 12:43, 10 November 2020 (UTC)

Wrap up of the survey & community feedback (9.11.2020)

Hello all,

Here’s some news from the review we’re currently running about our support process. Our goal is to understand how the current processes to report bugs and feature requests work for you, and how we could improve them. You can read more about the project on this page.

Thanks a lot to everyone who gave feedback or answered our survey. We collected 23 anonymous answers on the survey, and 5 people gave feedback on the talk page or on the social media channels. The majority of the survey respondents (87%) already reported a bug report or a feature request, the most used platform being Phabricator (42%), followed by WD:Contact the development team and WD:Project chat.

Asked to think of an example report or feature request that they made in the last 2 years that generally represents their overall opinion of interacting with the Wikidata development team, people mentioned a long delay of response, issues taking too long to be fixed, problems with tagging the report on Phabricator or difficulty to get in touch with people who could solve the issue. Overall, the lack of response or delay in the response seems to be the main pain points encountered by the respondents.

People were asked to rate on a scale of 1 to 5 how satisfied they are with the current process, and the results are pretty polarized: one third of the respondents declared being very satisfied, one third declared being not satisfied at all. Some respondents mentioned that they couldn’t get an answer before pinging people several times. Some people declared that they had a positive experience and the issue they reported was solved quickly.

Respondents were asked about improvements they thought could be made to the existing bug report/feature request process. The main suggestions revolve around:

• Having a better/clearer overview of the open bugs and already reported issues
• Improving the way tasks are triaged and monitored, as well as the creation of Phabricator tickets
• Being able to suggest and vote for the most important features and bugs to fix
• The possibility of communicating in other languages than English

On the positive side, some respondents declared that the existing process works well for them, and a few people mentioned Phabricator being functional as a bug tracking system. People highlighted the importance of an on-wiki channel to report problems.

Respondents who never made a feature request or report a bug before in the last two years had varied reasons for not doing so. 50% said that they expected someone else to do it, 16% said they did not know how to report a problem, while the rest of the respondents said that they didn’t encounter the need.

Thanks again to people who took some time to answer the survey. Our next steps are to work on some concrete suggestions to improve the process, and to come back to you so we can discuss how to implement them.

If you have any questions or more suggestions, feel free to add them on this talk page. Cheers, Mohammed Sadat (WMDE) & Lea Lacroix (WMDE), 10:07, 9 November 2020 (UTC)

Update - action plan for January-April 2021

Hello all,

Here’s an update on the support process review project, that has been ongoing since September last year. We didn’t give a lot of news on this page since the end of the survey, but we did a lot of work internally to analyze your feedback and come up with ideas that could help to solve the mentioned problems!

As a reminder, here are the main areas of improvement that we identified, together with you:

• Having a better/clearer overview of the open bugs and already reported issues
• Improving the way tasks are triaged and monitored, as well as the creation of Phabricator tickets
• Being able to suggest and vote for the most important features and bugs to fix
• The possibility of communicating in other languages than English
• Making processes and priorities more transparent
• Reducing the amount of channels where the development team actively provides support

For each area, we’ve been brainstorming on ways to solve these issues, identify the ideas that are possible to implement, and define feasibility and priority for each of them. We could select some concrete tasks that we can work on in the next months, and others that will be worked on later during the year.

These ideas include for example: communicate more about our development roadmap and our priorities (why we choose tasks over others), improve the “contact the development team” set of pages to improve the documentation on how to report an issue, encourage reports in languages other than English, improve the content and structure of tasks on Phabricator to help finding existing tasks, evaluate the possibility of joining WMF’s community wishlist and include community requests in our roadmap. These are just a few of them, you can find the full list here.

We will keep you updated on this page, for example to ask your feedback about the redesigned documentation page that we started working on. If you have any feedback, for example if some of the ideas don’t seem useful to you, or if you feel like something important is missing, feel free to add a comment under this message.

Thanks for your attention! Léa and Mohammed - Lea Lacroix (WMDE) (talk) 08:51, 20 January 2021 (UTC)

Thanks, I look forward to seeing how this moves forward now. ArthurPSmith (talk) 19:00, 20 January 2021 (UTC)

[Update] Support process review - May 2021

Hello,

Based on your feedback, we have been working on incorporating your inputs into redesigning the Wikidata:Contact the development team page. We suggest changing its name to make it less focused on the development team and a central place for all discussions about technical issues on Wikidata, where editors are welcome to help answer and support others. We introduced sub documentation pages so that it’s hopefully easier to navigate bug reports, and we will work on a better integration of multiple languages.

You can already have a look at Wikidata:Report a technical problem (it’s a draft page, still in construction)

We invite you to let us know if you feel like something important is missing by leaving a comment on this talk page by June 10th.

If you have any questions please feel free to ask.

Cheers,

-Mohammed Sadat (WMDE) (talk) 09:01, 27 May 2021 (UTC)

@Mohammed Sadat (WMDE): I will miss the former "Contact the development team" page. For me, the opportunity to directly write to the development team has been very useful. I agree with Jura that we already have several helpdesks which are used as centralplaces for "technical" questions. I also understand that this can sometimes be overwhelming for Wikimedia Germany - there are too many channels and too many feature requests. However, sometimes input from the developers on a difficult subject is really desirable and I do not know where else to ask then here. Phabricator is much better suited to clear bugs or clear feature requests.Vojtěch Dostál (talk) 12:54, 27 May 2021 (UTC)

Hi Vojtěch , thank you for your feedback.

While the main purpose of this page redesign is intended to be less focused on the development team, we’re going to still monitor the page as usual and answer questions that require developer’s input. Meaning that you can still expect to ask us questions that you’d otherwise have taken to WD:DEV and get feedback. What changes is really the emphasis to centralize all discussion around technical issues on Wikidata, of which both the community and the development team will then have a common space to work from.

Also, when you say we already have several helpdesks, do you mind letting us know which other page(s) you feel comfortable to use for technical questions? -Mohammed Sadat (WMDE) (talk) 15:05, 27 May 2021 (UTC)

@Mohammed Sadat (WMDE): OK, that does sound reasonable. It would be nice if WMDE team could acknowledge relevant discussions (Abián's suggestion above) as much as possible and give their thoughts on various technical matters. Really, your voice in discussions is essential. Also, as a Wikimedia chapter volunteer, I want to know how WMDE approaches various technical challenges - in cases where the dev team agrees with a given solution but does not have time or resources, other chapters might chip in and help. In a long term, that would lead to a certain decentralization, and that's what we kind of want in our strategy, right? :)

Other pages: Wikidata:Project chat (for general technical stuff - basically everything concerning Wikidata is technical, right?), Wikidata:Bot requests (for work which can be automated), Wikidata:Request a query (for questions on querying Wikidata), and maybe others.Vojtěch Dostál (talk) 16:55, 27 May 2021 (UTC)

Thanks for pointing out those pages!

Tracked in Phabricator
Task T90870

We do acknowledge the points raised in Abián's suggestions -- they’ve been an important part of our internal conversations. As you mention giving our thoughts on “various technical matters”: it is one of the reasons we want to centralize all technical discussions raised at different locations, so we do not lose sight of them.

About getting help from outside WMDE to accomplish development tasks, I’m happy to say that we’re very welcoming of that. We currently maintain a list of self-contained projects that people could take on. If a chapter is willing to take on something bigger than what is listed here then they should write to us so we can sit down together and talk about what would better suit their capacity. -Mohammed Sadat (WMDE) (talk) 17:41, 2 June 2021 (UTC)

Is there some way to add (bot-generated I guess?) reports on Phabricator tickets to that area so we can get an overview of the development work? For example, statistics on new tickets added, those completed, maybe partitioned by different development areas? Also there's a lot of user-generated development work regarding javascript gadgets or even css stuff that could be helpful to keep track of, maybe we can find a place to centralize that as well here? ArthurPSmith (talk) 16:53, 27 May 2021 (UTC)

@ArthurPSmith: Yes, we can generate lists that give an overview of tickets created / added, closed, etc. But to respond about what is truly possible as per tickets “partitioned by different development areas” do you mind explaining more about the kind of reports you’d like to see? If you could give an example, that’d be helpful.

Do keep in mind that a large part of our tickets are generally meant for our developers. There’s going to be A LOT in there that's absolutely not understandable to everyone, and so I do not think many people are actually going to find them useful.

Thanks for brining up the javascript and css work that the community have been contributing -- they’re an important part of the conversation and we’re thinking about how to incorporate them in the documentation pages. -Mohammed Sadat (WMDE) (talk) 11:12, 3 June 2021 (UTC)

On "different development areas" - when I go to the main Wikidata Phabricator board obviously it's a bit overwhelming, but different tickets there are tagged with what area they are related to - 'Wikidata Lexicographical data', 'Wikibase-Quality-Constraints', 'ArticlePlaceholder', etc. So some overview of that hierarchy or whatever you want to call it would be nice! ArthurPSmith (talk) 14:25, 3 June 2021 (UTC) @Mohammed Sadat (WMDE): Sorry missed the ping the first time. ArthurPSmith (talk) 14:25, 3 June 2021 (UTC)