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 about stuff you rather want to throw out
> - new features and changes that are advertised but never implemented

Could you please provide a specific example (link) for the last item?

> The first one is perhaps the one most easily fixed. I believe WMF
> could set up either an official bug squad

In my understanding a bug squad does not write patches but triages
tickets. Maybe you meant a patchsquad or Gerrit wrangler (in case you
refer to *existing* simple fixes, which is not clear from your words).
Not sure why there is call to some authority ("WMF") here.

> or use bug bounties to speed up fixing of bugs. I tend to believe bug
> bounties works best, but it would be really nice to know that bugs
> are handled in an orderly fashion by a bug squad.

See https://phabricator.wikimedia.org/T88265#1870218 for risks and
(dis)advantages of bug bounties. 
Note that throwing more 'external' developers onto code does not
necessarily "speed up fixing of bugs". Often to the contrary.

> When introducing new features make a help page at Meta or Mediawiki,
> and link to the page from the feature. 

Looking at the beta features section at
https://meta.wikimedia.org/wiki/Special:Preferences#mw-prefsection-betafeatures
all beta features have "Discussion" and "Information" links.
What you are suggesting already happens.

> On that page make a visible link "Don't panic!" and link to the issue
> tracker. Don't expect the users to figure out which extension
> provides the specific feature, they don't have a clue. 
> For all important issues make an estimated fix time, and if no one
> works on the issue say so. 

When nobody works on an issue, Phabricator's "Assigned To" field
usually shows "None". What you are suggesting already happens.

Cookie licking can happen though (means: someone assigns a ticket to
themselves and then does not work on it). It's up to each assignee to
occasionally check which tasks are (still) assigned to them:
https://phabricator.wikimedia.org/maniphest/query/5INV_avtCreJ/#R

> Don't assume the users understand fancy wording about "need
> volunteer". Need volunteer for what? Making coffee?
> 
> Some features are described in Phabricator, which is fine, but some
> of
> them has extensive cookie licking which could give someone the
> impression that you actually will implement the feature.

Could you please provide a specific example (link) for this?

> That often leads to users asking about the feature, and when it will
> arrive at their project. When it does not arrive users gets upset. If
> you are working on something, say it, but also be very clear if
> something has gone into you personal freezer.

Cheers,
andre
-- 
Andre Klapper | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to