I sometimes see WMF developers and product managers marking tasks as
"Declined" with comments such as these:
* "No resources for it in (team name)"
* "We won't have the resources to work on this anytime soon."
* "I do not plan to work on this any time soon."
Can we perhaps agree that the "Declined" status shouldn't be used like this?
"Declined" should be valid when:
* The component is no longer maintained (this is often done as
* A product manager, a developer, or any other sensible stakeholder thinks
that doing the task as proposed is a bad idea. There are also variants of
* The person who filed the tasks misunderstood what the software component
is supposed to do and had wrong expectations.
* The person who filed the tasks identified a real problem, but another
task proposes a better solution.
It's quite possible that some people will disagree with the decision to
mark a particular task as "Declined", but the reasons above are legitimate
However, if the task suggests a valid idea, but the reason for declining is
that a team or a person doesn't plan to work on it because of lack of
resources or different near-term priorities, it's quite problematic to mark
it as Declined.
It's possible to reopen tasks, of course, but nevertheless "Declined" gives
a somewhat permanent feeling, and may cause good ideas to get lost.
So can we perhaps decide that such tasks should just remain Open? Maybe
with a Lowest priority, maybe in something like a "Freezer" or "Long term"
or "Volunteer needed" column on a project workboard, but nevertheless Open?
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
“We're living in pieces,
I want to live in peace.” – T. Moore
Code Health Newsletter
The Code Health newsletter is a monthly publication provided by the
Code Health Group. The Code Health Group serves as the hub for all
Code Health topics and activities within the movement. If you are
aware or engaged in Code Health activities, we'd love to hear about
# First Responders
Staying with the Health theme, First Responders are those
individuals that have made strides in improving their code's health.
These efforts will hopefully act as stories of inspiration for others
to take on improving their code's health.
Do you have a story to share? Become or nominate a First Responder by
submitting a task in Phabricator in the #Code-Health-First-Responder
project. If sharing inspiration isn't enough, how about a cool free
First Responder t-shirt (more about that coming soon).
# Code Stewardship
Code Stewardship is an approach that the Wikimedia Foundation has
adopted to help ensure that components, extensions, and services that
are deployed to the production infrastructure have the necessary
support throughout their lifetime.
To date, the Code Stewardship review process has helped identify
and find Code Stewards for 10 components, extensions, or services that
were un/under-supported. The goal is to have complete Code Steward
coverage for all deployed-to-production components, extensions, and
services. Although we are not there yet, we are working towards that
goal every day.
This quarter's review window has closed. More information about how
to submit a review candidate is available on the Code Stewardship
review process wiki page.
Latest Code Stewardship Coverage
Core Components: 63%
Note: these numbers are based on the Developers/Maintainers page.
# Code Health by the Numbers
The following are some stats regarding Code Health. As we are early
in defining/implementing our Code Health metrics, data is limited.
See the Code Health Metrics project for more information.
In future issues of the newsletter, we'll expand this section to
include other metrics as well as trending information.
## Code Coverage
0-50% 51-90% 90-100%
Extensions 71 13 4
Code Components 5 10 18
Services Not Available Yet
Note: As of 9/30/18.
# Code Health Learning Circles
Learning Circles are an effective way to share knowledge and
experience with your peers. Although Learning Circles have been done
in one form or another for quite some time, we've decided to do our
best to promote more Code Health related sessions. More information
about Code Health Learning Circles available here.
If you have a topic that you'd like to share, but want a little help
with organizing, please submit a Phabricator ticket to the
Topic: Design Principles and Code Refactoring
Presenter: Guillaume Lederrey
#Code Health Group Activities
Although the Code Health Group looks to act as a hub for all code
health topics, the group also sponsors various broader reaching
Code Health Metrics
Code Health Metrics working group has been formed. This working
group will focus on defining a core set of metrics that we can use to
assess code health. If you're interested in Code Health metrics
please engage in the discussion on the Discussion page and/or IRC
Up Coming Activities:
Code Health Office Hours
The Code Health Group is sponsoring a new bi-weekly Code Health Office
Hours starting October 16th at 3:00pm (15:00). These sessions are to
be held in Goggle Meet.
Do you have a Code Health topic that you need help with? Advice about
refactoring, tech debt, unit testing, etc... This is the place to ask
for it. Please submit a Phabricator task to the
#Code-Health-Help-Wanted project and the Code Health Group will do its
best to point you in the right direction.
That wraps up this inaugural issue of the Code Health Newsletter. If
you have any suggestions and/or want to see other topics, feedback is
welcome. Please just reply to this email.
The Search Platform Team
<https://www.mediawiki.org/wiki/Wikimedia_Search_Platform> will be holding
office hours the first Wednesday of each month, starting next week. Come
ask us anything about Wikimedia search!
We’re particularly interested in:
* Opportunities for collaboration—internally or externally to the Wikimedia
* Challenges you have with on-wiki search, in any of the languages we
But we're happy to talk about anything search-related.
Details for our next meeting:
Date: Wednesday, October 3rd, 2018
Time: 15:00 GMT / 08:00 PDT / 11:00 EDT / 17:00 CEST
Google Meet link: https://meet.google.com/vyc-jvgq-dww
*N.B.:* Google Meet System Requirements
See you there!
Sr. Software Engineer, Search Platform
Reminder: Technical Advice IRC meeting again **Wednesday at 3-4 pm UTC AND
11-12 pm UTC** on #wikimedia-tech.
The Technical Advice IRC Meeting (TAIM) is a weekly support event for
volunteer developers. Every Wednesday, two full-time developers are
available to help you with all your questions about Mediawiki, gadgets,
tools and more! This can be anything from "how to get started" over "who
would be the best contact for X" to specific questions on your project.
If you know already what you would like to discuss or ask, please add your
topic to the next meeting:
Hope to see you there!
Michi (for the Technical Advice IRC Meeting crew)
Michael F. Schönitzer
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
Hi Community Metrics team,
This is your automatic monthly Phabricator statistics mail.
Accounts created in (2018-09): 310
Active Maniphest users (any activity) in (2018-09): 884
Task authors in (2018-09): 507
Users who have closed tasks in (2018-09): 278
Projects which had at least one task moved from one column to another on
their workboard in (2018-09): 317
Tasks created in (2018-09): 2518
Tasks closed in (2018-09): 1940
Open and stalled tasks in total: 39517
Median age in days of open tasks by priority:
Unbreak now: 16
Needs Triage: 431
(How long tasks have been open, not how long they have had that priority)
Active Differential users (any activity) in (2018-09): 15
TODO: Numbers which refer to closed tasks might not be correct, as
described in https://phabricator.wikimedia.org/T1003 .
Fab Rick Aytor
(via community_metrics.sh on phab1001 at Mon Oct 1 00:00:25 UTC 2018)