Greetings!
We are beginning the process of working on the 1.32 release of
MediaWiki. The release is currently scheduled for Nov. We plan to create
the REL1_32 branch on October 16 and to generate the first release
candidate, so we will be requesting "pencils down" on October 15.
In the meantime, if you have any open Phabricator tasks tagged with
mw-1.32-release [0], please check to see if they are indeed blockers for
the release. If not, please remove the mw-1.32-release tag from them.
Conversely, if there are any blockers that are not tagged with
mw-1.32.release, please tag them. Please feel free to reach out to me if
you have any questions about this.
We will be in the normal patch master + backport process from October 16
until the release in Nov.
Thanks,
Greg
[0] https://phabricator.wikimedia.org/tag/mw-1.32-release/
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| Release Team Manager A18D 1138 8E47 FAC8 1C7D |
Hi,
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
mass-declining).
* 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
this:
* 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
explanations.
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 · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Code Health Newsletter
The Code Health[0] newsletter is a monthly publication provided by the
Code Health Group[1]. 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
it.
# First Responders
Staying with the Health theme, First Responders[2] 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[3] 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[4] 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[4].
Latest Code Stewardship Coverage
Core Components: 63%
Extensions: 74%
Services: 65%
Note: these numbers are based on the Developers/Maintainers[5] 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[6] 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[10].
# 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[6].
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
#Code-Health-Learning-Circles project.
Newly Added:
Topic: Design Principles and Code Refactoring
Presenter: Guillaume Lederrey
Link: https://commons.wikimedia.org/wiki/File:Learning_Circle_CodeRefactoring_Gui…
#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
initiatives.
Recent Activities:
Code Health Metrics
Code Health Metrics[7] 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[8] and/or IRC
#wikimedia-codehealth.
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[9].
#Help Wanted
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.
# Summary
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.
Cheers,
JR
[0]https://www.mediawiki.org/wiki/Code_Health
[1]https://www.mediawiki.org/wiki/Code_Health_Group
[2]https://www.mediawiki.org/wiki/Code_Health/First-Responders
[3]https://www.mediawiki.org/wiki/Development_policy/Code_Stewardship
[4]https://www.mediawiki.org/wiki/Code_stewardship_reviews
[5]https://www.mediawiki.org/wiki/Developers/Maintainers
[6]https://www.mediawiki.org/wiki/Code_Health_Group/Learning_Circles
[7]https://www.mediawiki.org/wiki/Code_Health_Group/projects/Code_Health_Met…
[8]https://www.mediawiki.org/wiki/Talk:Code_Health_Group/projects/Code_Healt…
[9]https://meet.google.com/umj-usbi-sjk
[10]https://doc.wikimedia.org/cover/
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
Foundation
* Challenges you have with on-wiki search, in any of the languages we
support
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
<https://support.google.com/meet/answer/7317473>
See you there!
—Trey
Trey Jones
Sr. Software Engineer, Search Platform
Wikimedia Foundation
Hi All,
A friendly reminder that TechCom is hosting an IRC discussion tomorrow
on RFC: Spec for representing multiple content objects per revision
(MCR) in XML dumps: <https://phabricator.wikimedia.org/T199121>
This RFC is about how the content of multiple slots should be
represented in XML dumps.
The meeting is scheduled for Wednesday 3 October at 2pm PST(21:00 UTC,
23:00 CET) in #wikimedia-office.
If you haven't joined a #wikimedia-office meeting before more
information can be found here:
<https://meta.wikimedia.org/wiki/IRC_office_hours#How_to_participate>
More information regarding the TechCom RFC process is available here:
<https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Processes#RFC_…>
Thanks,
Kate
--
Kate Chapman TechCom Facilitator (Contractor)
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:
https://www.mediawiki.org/wiki/Technical_Advice_IRC_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
http://wikimedia.de
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
http://spenden.wikimedia.de/
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
High: 726
Normal: 993
Low: 1306
Lowest: 1250
(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 .
Yours sincerely,
Fab Rick Aytor
(via community_metrics.sh on phab1001 at Mon Oct 1 00:00:25 UTC 2018)