Hi!
> Yes, there should always be a response to all bugs. Without a response
> the impression in the reporting wiki-community would be "nobody cares
> about our bug reports".
Would a canned "thank you for your feedback, please stay on the line,
your call is very important to us" response make
On Wed, 2019-03-13 at 01:22 +0100, John Erling Blad wrote:
> What frustrates me the most are
>
> - bugs found by the editor community, that has obvious simple fixes,
> which isn't acted upon for several years
> - new features that isn't fully tested, and you have to answer in the
> community
On Wed, Mar 13, 2019 at 3:02 PM Strainu wrote:
> The main problem I see with the community wishlist is that it's a
> process beside the normal process, not part of it. The dedicated team
> takes 10 bugs and other developers another ~10. I think we would be
> much better off if each team at the
On Thu, Mar 14, 2019 at 4:36 AM John Erling Blad wrote:
> Google had a problem with unfixed bugs, and they started identifying
> the involved developers each time the build was broken. That is pretty
> harsh, but what if devs somehow was named when their bugs were
> mentioned? What if there were
I ment, when you open the unread page, it is marked as read.
Igal
בתאריך יום ה׳, 14 במרץ 2019 ב-19:37 מאת Brad Jorsch (Anomie) <
bjor...@wikimedia.org>:
> On Thu, Mar 14, 2019 at 1:29 PM יגאל חיטרון
> wrote:
>
> > From time to time the API post query "mark this revision as read"
This sounds like it could have been caused by
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/416198
On Thu, Mar 14, 2019 at 10:29 AM יגאל חיטרון
wrote:
> Hello. There is a regression problem, that started on this week deployment.
> I can see it in group 1 from yesterday evening. I do
On Thu, Mar 14, 2019 at 1:29 PM יגאל חיטרון
wrote:
> From time to time the API post query "mark this revision as read" does not
> work.
Nothing in the reproduction steps you list does such a post query.
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
Hello. There is a regression problem, that started on this week deployment.
I can see it in group 1 from yesterday evening. I do not file a phabricator
ticket, because there is no algorithm to reproduce the problem.
From time to time the API post query "mark this revision as read" does not
work.
On Thu, 2019-03-14 at 15:50 +0100, John Erling Blad wrote:
> Yes, there should always be a response to all bugs. Without a response
> the impression in the reporting wiki-community would be "nobody cares
> about our bug reports".
>
> Someone in the community finds a bug, and it is posted and
‐‐‐ Original Message ‐‐‐
On Thursday, March 14, 2019 3:56 PM, David Barratt
wrote:
> Is the Wikimedia Foundation responsible for people's emotions?
Yes. Frustration, mostly. It is not entirely unexpected that this message
originates from @wikimedia.org.
Is the Wikimedia Foundation responsible for people's emotions?
On Thu, Mar 14, 2019 at 10:51 AM John Erling Blad wrote:
> Yes, there should always be a response to all bugs. Without a response
> the impression in the reporting wiki-community would be "nobody cares
> about our bug reports".
>
>
Yes, there should always be a response to all bugs. Without a response
the impression in the reporting wiki-community would be "nobody cares
about our bug reports".
Someone in the community finds a bug, and it is posted and discussed
in the community. Then another one writes a report in a task at
Hello everyone,
I'm pleased to announce that we've released OOUI v0.31.0 yesterday.
Key highlights of this release:
- IndexLayout (tab layout) and all its dependent layouts
- StackLayout,
- MenuLayout,
- TabPanelLayout and TabSelectWidget/TabOptionWidget
are all now provided server-side in
Sorry, but I try to point out that the process is broken and give a
few examples on how to fix the process.
On Thu, Mar 14, 2019 at 1:20 PM Andre Klapper wrote:
>
> On Thu, 2019-03-14 at 12:35 +0100, John Erling Blad wrote:
> > Blame games does not fix faulty processes.
>
> Hmm, why is this
Hi all,
Version 2.10 of the Commons Android app has just been released to
production on the Google Play Store[1] (also downloadable on F-Droid[2]).
The update contains:
New features:
- Users can search for (and upload pictures for) places that need pictures
in any location, not just their
On Tue, 2019-03-12 at 00:29 +0100, John Erling Blad wrote:
> It seems like some projects simply put everything coming from external
> sources into deep freezer or add "need volunteer". If they respond at
> all. In some cases it could be that the projects are defunc.
What's the expectation based
On Thu, 2019-03-14 at 12:35 +0100, John Erling Blad wrote:
> Blame games does not fix faulty processes.
Hmm, why is this thread called "Question to WMF" instead of "Question
to developers"?
> Why do we have bugs that isn't handled for years?
Basically: Because you did not fix these bugs. Longer
Blame games does not fix faulty processes. You fix a sinkhole by
figuring out where the water comes from and where it goes.
Why do we have bugs that isn't handled for years? Why is it easier to
get a new feature than fixing an old bug?
Google had a problem with unfixed bugs, and they started
If you use these dumps regularly, please read and weigh in here:
https://phabricator.wikimedia.org/T216160
Thanks in advance,
Ariel Glenn
Wikimedia Foundation
ar...@wikimedia.org
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
În joi, 14 mar. 2019 la 01:02, Amir Sarabadani a scris:
>
> On Wed, Mar 13, 2019 at 11:02 PM Strainu wrote:
>
> > - ContentTranslation v1 (obsolete now, has been unmaintained for 2
> > years while in production)
> > - UploadWizard (2 with high priority, 40 with normal, a few dozens
> > low,
Oh, thanks, it looks usable. As far as i understand this flagged data contains
stable revision for pages, which are have pending changes protection enabled
and when flag is missing means it is disabled, is that correct?
Also is it possible to get all page revisions through this generator, so i
21 matches
Mail list logo
