Re: [Wikitech-l] problematic use of "Declined" in Phabricator

[Pine W]

Regarding 'A recent unrelated ticket I made was closed  with the "no
resource to waste on that" by a product owner.': I think that civil
messages explaining why a ticket won't be addressed would be helpful, as
would civil messages explaining why tasks are being moved to a "freezer",
instead of moves, closures, etc. with no explanation or with somewhat
insulting comments. Messages don't need to be elaborate, and can be
copypasted, so long as they explain in civil terms what's happening and
why. Keep in mind that some people who submit tickets may not natively
communicate in English, and may have little familiarity with the Wikimedia
use of Phabricator.

Regarding where to discuss proposals that address issues that have been
raised in this thread, as I said earlier, I suggest a wiki talk page.

Pine
( https://meta.wikimedia.org/wiki/User:Pine )
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Code Health Newsletter - Issue 1 Volume 1

[Pine W]

Hello,

Thank you for this info. I share an interest in the maintainability of code
that may be around for years, long after the people who write it are no
longer involved with Wikimedia.

It sounds like the Code Health Group is effectively an internal special
interest group for Wikimedia people (I am hoping that it isn't exclusive to
WMF staff) who share an interest in "code health", but isn't a top-down
decision-making body like TechCom. Is that correct?

One thing that I would like to request is a change of terminology. I prefer
to reserve the term "first responder" in the Wikiverse for people who are
actually on the front lines doing time-critical work, such as  volunteer
administrators and functionaries who address threats, harassment, and other
issues with legal and security implications; WMF staff who respond to
emergency@ tickets; and staff and volunteers who deal with urgent technical
problems of various kinds and are on call 24/7 for that purpose.
Accordingly, I would request that you replace your use of "first responder"
with a different term; it's fine to use a term that sounds attractive, but
preferably one that doesn't already have a different (and in this case,
very important) meaning. Perhaps I'm excessively defensive and biased, so
take my opinion with a grain of salt, but as someone who occasionally deals
with certain issues on a 24/7 basis, I think that the term "first
responder" should be reserved.

Thank you,

Pine
( https://meta.wikimedia.org/wiki/User:Pine )


On Wed, Oct 3, 2018 at 10:44 PM Jean-Rene Branaa 
wrote:

> 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  134
> 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_Guillaume_Lederrey.webm
>
>
> #Code Health Group Activities
>
> Although the Code Health Group looks 

[Wikitech-l] Code Health Newsletter - Issue 1 Volume 1

[Jean-Rene Branaa]

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  134
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_Guillaume_Lederrey.webm


#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_Metrics

Re: [Wikitech-l] Collecting UI feedback for PolyGerrit - Gerrit

[Thiemo Kreuz]

Paladox wrote:

> i am collecting feedback for Gerrit's New UI […]

You might want to check out the CSS tweaks I developed for the old
Gerrit UI. This stylesheet removes a lot of clutter, makes Gerrit
usable on smaller laptop screens, and increases critical click
regions. If the new Gerrit UI looks as clean as my tweaked version (or
when similar tweaks can be applied to the new UI), I'm happy.

https://meta.wikimedia.org/wiki/User:Thiemo_Kreuz_(WMDE)/userContent.css

Best
Thiemo

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

Re: [Wikitech-l] Collecting UI feedback for PolyGerrit - Gerrit

[Paladox via Wikitech-l]

 For point1, there is now status badges on change screens. On the dashboard 
text is highlighted to tell if it's merged/abandoned/wip/private.
For point 2, upstream have implemented that which will be part of 2.16.
For point 3 they changed it on smaller screens so it would take less space (i 
think)
For point 4 that's already possible, just click "save" and not "start review"
On Wednesday, 3 October 2018, 22:56:41 BST, Stas Malyshev 
 wrote:  
 
 Hi!

Some tweaks that I found useful to do for myself in new UI (some can be
done custom styles/scripts etc.) and that might be interesting to
implement if possible:

1. Color coding of changes on the dashboard:
- one with +1 gets green
- one with -1/-2 gets red
- one that has merge conflict gets its own distinct color
This allows to quickly see which items can be reviewed/merged, which
ones need work, which need rebase, etc.

2. On dashboard, Owner column gets too wide sometimes. Some names are
pretty long and this space would be best used by Subject - which I do
want to see in its entirety, unlike the name for which the prefix is
almost always OK.
In fact, if we could also compress "Status" column somehow it'd be even
nicer - "Merge Conflict" message is useful but takes way too much
precious space.

3. In change view, sometimes the "related changes" box consumes too much
space, you can see it on https://phabricator.wikimedia.org/F26296242 -
it takes almost half horizontal space, despite being way less important
than the patch description. It'd be nice to put a constraint on it

4. It would be nice to be able to add people to WIP tasks without moving
it to Review status. Sometimes several people may need to cooperate on
WIP patch before it is ready to go. Of course, one can add reviwer and
then move back to WIP, but it'd be nicer to avoid extra actions.

Thanks!
-- 
Stas Malyshev
smalys...@wikimedia.org
  
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Collecting UI feedback for PolyGerrit - Gerrit

[Stas Malyshev]

Hi!

Some tweaks that I found useful to do for myself in new UI (some can be
done custom styles/scripts etc.) and that might be interesting to
implement if possible:

1. Color coding of changes on the dashboard:
- one with +1 gets green
- one with -1/-2 gets red
- one that has merge conflict gets its own distinct color
This allows to quickly see which items can be reviewed/merged, which
ones need work, which need rebase, etc.

2. On dashboard, Owner column gets too wide sometimes. Some names are
pretty long and this space would be best used by Subject - which I do
want to see in its entirety, unlike the name for which the prefix is
almost always OK.
In fact, if we could also compress "Status" column somehow it'd be even
nicer - "Merge Conflict" message is useful but takes way too much
precious space.

3. In change view, sometimes the "related changes" box consumes too much
space, you can see it on https://phabricator.wikimedia.org/F26296242 -
it takes almost half horizontal space, despite being way less important
than the patch description. It'd be nice to put a constraint on it

4. It would be nice to be able to add people to WIP tasks without moving
it to Review status. Sometimes several people may need to cooperate on
WIP patch before it is ready to go. Of course, one can add reviwer and
then move back to WIP, but it'd be nicer to avoid extra actions.

Thanks!
-- 
Stas Malyshev
smalys...@wikimedia.org

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

[Wikitech-l] Collecting UI feedback for PolyGerrit - Gerrit

[Paladox via Wikitech-l]

Hi, i am collecting feedback for Gerrit's New UI called PolyGerrit. It's 
possible to use PolyGerrit on gerrit.wikimedia.org since 2.14. The new UI has 
recently been made the default upstream. The Old UI is going away in the next 
release after 2.16. Upstream have given PolyGerrit another update that looks 
different to the one on gerrit.wikimedia.org. PolyGerrit now includes a dark ui.

To switch to PolyGerrit either click the "New UI" button on the footer or put 
?polygerrit=1 in the url.

To switch back to GWTUI either click "Switch back to old ui" on the footer or 
put ?polygerrit=0 in the url.

Non dark mode:

Here's how it looks like:

Dashboard:

https://phabricator.wikimedia.org/F26296230


Change list:

https://phabricator.wikimedia.org/F26296240

Change screen:

https://phabricator.wikimedia.org/F26296242


https://phabricator.wikimedia.org/F26296257


Dark mode: https://phabricator.wikimedia.org/F26296282


And many other UI improvements across the app.

You can play around the the new ui from the master branch that will become 2.16 
here https://gerrit.git.wmflabs.org/r/

Please give feedback so upstream can make PolyGerrit even better! You can 
either file your reports at https://phabricator.wikimedia.org/project/view/330/ 
or reply to the email with your feedback.




It has a dedicated team on the UI with a design researcher behind the scenes 
redesigning polygerrit constantly based on feedback.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] problematic use of "Declined" in Phabricator

[Strainu]

În mie., 3 oct. 2018 la 19:08, Mathieu Lovato Stumpf Guntz
 a scris:
> On the other hand, I discovered in the process that for some other people in 
> the community phabricator is perceived as an hostile place, out of what they 
> feel as part of "their" community. Actually, to the point that starting a 
> proposal on phabricator might be  interpreted as an attempt to enforce ideas 
> without and against the consent of the community, rather than a call to give 
> feedback and make evolve ideas together, and thus despite an immediate 
> communication on the ticket creation.

That's a totally orthogonal problem that existed from the bugzilla
days. Some people consider bug tracking as a "dev" activity that they
don't know anything about, others have difficulties communicating in
English and finally some just consider the WMF evil and want nothing
to do with it. Using Phabricator to track bugs and features in a
certain way (or at all) doesn't seem to have a lot to do with this
(unless there is some proof to the contrary that I'm not aware of).

The problem Amir brought up mainly affects people that already use Phabricator.

Strainu

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

Re: [Wikitech-l] problematic use of "Declined" in Phabricator

[Mathieu Lovato Stumpf Guntz]

I'm not sure it is a so focused issue. A recent unrelated ticket I made was 
closed  with the "no resource to waste on that" by a product owner.

A first thing is that I want to work on this issue, and would find that useful 
to use phabricator to track that task even if no specific resource would be 
dedicated to it beyond my own attention. On that regard, I red again the 
documentation and concluded that it was fine to reopen it in regard to what it 
is stated on ticket status life cycles. So far so good, I would say. 

On the other hand, I discovered in the process that for some other people in 
the community phabricator is perceived as an hostile place, out of what they 
feel as part of "their" community. Actually, to the point that starting a 
proposal on phabricator might be  interpreted as an attempt to enforce ideas 
without and against the consent of the community, rather than a call to give 
feedback and make evolve ideas together, and thus despite an immediate 
communication on the ticket creation. 

That's what make me think that the issue discussed here is far deeper and have 
a great psychological effect on the cohesion of the Wikimedia community. 

Cheers



Le 2 octobre 2018 19:24:23 GMT+02:00, Michael Holloway 
 a écrit :
>I think I can provide some context here, because this really seems to
>be
>about something specific.  The Reading Infrastructure team recently
>inherited maintenance responsibility for the Wikimedia maps stack,
>resourced on a very limited basis.  Along with that, we inherited a
>backlog
>of many hundreds of tasks, many of which have seen no activity for
>years.
>For the past couple of months, a few of us have spent an hour each week
>trying to work through the backlog trying to triage all of these.  In
>the
>course of these grooming meetings, we have closed more than a few tasks
>based on a combination of not having the resources to work on them, and
>it
>not seeming likely that anyone else will, either; the theory here is
>that
>it can better reflect reality to openly decline a task than to let it
>languish in a backlog indefinitely.
>
>If this contravenes the relevant norms, I apologize.  If you were upset
>by
>the closing of what you believe to be a valid maps ticket, please feel
>free
>to reopen.  Thanks.
>
>On Tue, Oct 2, 2018 at 10:06 PM Brian Wolff  wrote:
>
>> Declined = WONTFIX (e.g. if some talented developer wrote a patch,
>and the
>> patch was perfect, you would still -2 it because the functionality is
>not
>> wanted/stupid/etc)
>>
>> Invalid = not a real bug. That should include things like spam, stuff
>where
>> the reporter is mistaken ( can't reproduce or if someone say reports
>a
>> sharepoint bug)
>>
>> I think the defining difference is its possible to write a patch for
>a
>> declined bug, even though it would be rejected, where an invalid bug
>by
>> definition is unfixable.
>>
>> Just my 2 cents, others may have different definitions.
>>
>> --
>> Brian
>>
>> p.s. ive never liked the "need volunteer" term for lowest priority -
>I have
>> always felt it had offensive implications as if volunteer time isnt
>as
>> important so they get the low priority bugs.
>>
>> On Tuesday, October 2, 2018, Joe Matazzoni 
>> wrote:
>> > I agree with Amir’s understanding. "Declined” is basically for
>ideas
>> whose proper timing is never.  Valid ideas that we just aren’t going
>to
>> work on any time soon should go in a backlog or freezer or some such,
>where
>> they can await until some future project or other development makes
>them
>> relevant (at least theoretically).
>> >
>> > All of which does raise a slightly different question: I am much
>less
>> clear on what the exact difference is between “Invalid” and
>“Declined.”
>> Thoughts?
>> >
>> > Best,
>> > Joe
>> > _
>> >
>> > Joe Matazzoni
>> > Product Manager, Collaboration
>> > Wikimedia Foundation, San Francisco
>> > mobile 202.744.7910
>> > jmatazz...@wikimedia.org
>> >
>> > "Imagine a world in which every single human being can freely share
>in
>> the sum of all knowledge."
>> >
>> >
>> >
>> >
>> >> On Oct 2, 2018, at 9:31 AM, Amir E. Aharoni <
>> amir.ahar...@mail.huji.ac.il>
>> wrote:
>> >>
>> >> 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 

Re: [Wikitech-l] problematic use of "Declined" in Phabricator

[Jon Robson]

Just one note about "needs-volunteer".
If the staff maintaining an extension don't have time to work on a problem,
they may also not have time to review any changes relating to it.

If you do use this tag, I see this as an indication you are willing to take
time to review any contributions relating to that task and do so until the
task is seen to completion.

There is nothing I hate more than seeing volunteers submit patches to help
the project and not getting any code review. Our volunteers are important.


On Wed, 3 Oct 2018 at 05:15 Derk-Jan Hartman 
wrote:

> Another side effect of closing a ticket with Declined, is that it doesn't
> show up in search (because it's closed and closed tickets are omitted by
> default). But if the problem or desire for the feature still exists, it is
> likely to be reported again by users via a new ticket and other people then
> have to go duplicate hunting. So that creates more duplicates to weed
> through.
>
> And when I work on something, I often take a look at boards and see if
> there is anything else in the same area that might need work, or I use the
> tickets to get a feeling of the direction that people want us to go. When
> declined is mixed with "we can't work on this right now", that makes it a
> lot harder to do that as well.
>
> So i think Stalled is better. The problem with that can be that such
> tickets show up in workboards, which can create a lot of load in the
> browser if there are a lot of tickets. If we would tag all of such tickets
> with something like 'need-volunteer', a team could customise their work
> board filter to exclude all tickets with that tag. Or simply exclude the
> entire status, but then you cannot effectively use it within the team
> either. We do have to make that need-volunteer tag somewhat better defined
> in the bug lifecycle and the tag's description in that case. That tag
> started out more as an "opportunities for volunteers". Alternative is a new
> "no-resourcing" tag. or something.
>
> DJ
>
> On Wed, Oct 3, 2018 at 1:03 PM Amir Sarabadani 
> wrote:
>
> > My two cents:
> > I would personally make those type of tickets as "stalled", "stalled"
> > basically for me means blocked and these type of tasks are blocked on
> human
> > resources, some miracles might happen and we might end up having enough
> > resources to unblock it but until that day it's stalled IMO.
> >
> > OTOH there are tickets that we don't have resources to work on it and we
> > never will, imagine a ticket with title "Rewrite mediawiki", it sounds
> good
> > as lots of part of it is old but we will never have such resource to do
> it.
> > IMO, we should call it declined on grounds of not having resources. Same
> > goes for "Every user should have a personal private wiki": We don't have
> > hardware resources for that and probably never will.
> >
> > Best
> >
> > On Wed, Oct 3, 2018 at 7:27 AM Pine W  wrote:
> >
> > > I'm grateful for this largely civil and productive discussion. I'd like
> > to
> > > suggest that the multiple sub-topics being discussed here might be
> easier
> > > to follow if the entire discussion is moved to a wiki talk page, such
> as
> > on
> > > MediaWiki.org. I am not attempting to halt discussion or to tell people
> > to
> > > stop writing to the mailing list; moving to a wiki talk page is just a
> > > suggestion.
> > >
> > > Thanks,
> > >
> > > Pine
> > > ( https://meta.wikimedia.org/wiki/User:Pine )
> > > ___
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- 
Jon Robson
twitter: @jdlrobson
linkedin: https://www.linkedin.com/in/jorobson/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Datacenter switchover and switchback

[C. Scott Ananian]

Oct 8 seems to be a particularly bad time to freeze the train given that we
are forking for the MW 1.32 release on Oct 15, and a lot of folks have
last-minute things they want to get into the release (eg deprecations, etc).
  --scott

On Thu, Aug 30, 2018 at 10:57 AM Pine W  wrote:

> +1 to DJ's question about timing. Also, one might wish to be mindful of
> the number of recent trains that were supposed to be boring but involved
> interesting surprises; this makes me wonder whether trains that one thinks
> will be boring are actually OK in this circumstance even if they turn out
> to be "interesting".
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
>
>
>
>  Original message From: Derk-Jan Hartman <
> d.j.hartman+wmf...@gmail.com> Date: 8/30/18  2:54 AM  (GMT-08:00) To:
> Wikimedia developers  Subject: Re:
> [Wikitech-l] Datacenter switchover and switchback
> While I think these regular switches are a very good idea, from an outside
> perspective I do have to question a process that puts a significant plug in
> the velocity of various teams working on major projects (esp. in a time of
> year that could probably be seen as one of the most productive). What are
> plans to reduce the disruption of this exercise in the future ?
>
> DJ
>
> On Thu, Aug 30, 2018 at 8:38 AM Jaime Crespo 
> wrote:
>
> > Let me explain the rationale of the bellow request for clarification:
> >
> > On Wed, Aug 29, 2018 at 11:30 PM MA  wrote:
> >
> > > Hello:
> > >
> > > >For the duration of the switchover (1 month), deployers are kindly
> > > >requested to refrain from large db schema changes and avoid deploying
> > > >any kind of new feature that requires creation of tables.
> > > >There will be a train freeze in the week of Sept 10th and Oct 8th.
> >
> >
> > During the failover, some schema changes will be finalized on the current
> > active datacenter (plus some major server and network maintenance may be
> > done)- our request is mostly to refrain from quickly enabling those large
> > new unlocked features (e.g. the ongoing comment refactoring, actor/user
> > refactoring, Multi Content Revision, JADE, major wikidata or structured
> > comons structure changes, new extensions not ever deployed to the
> cluster,
> > etc.) at the same time than the ongoing maintenance to reduce variables
> of
> > things that can go bad- enabling those features may be unblocked during
> the
> > switchover time, but we ask you to hold until being back on the current
> > active datacenter. Basically, ask yourself if you are enabling a large
> new
> > core feature or want to start a heavy-write maintenance script and there
> is
> > a chance you will need DBA/system support. Sadly, we had some instances
> of
> > this happening last year and we want to explicitly discourage this during
> > these 2 weeks.
> >
> > In own my opinion, enabling existing features on smaller projects (size
> > here is in amount of server resources, not that they are less important)
> is
> > equivalent to a swat change, and I am not against it happening. I would
> ask
> > contributors to use their best judgement on every case, and ask people on
> > the #DBA tag on phabricator or add me as reviewers on gerrit if in doubt.
> > My plea is to not enable major structural changes during that time may
> > affect thousands of edits per minute. Swat-like changes and "boring" :-)
> > trains are ok.
> >
> > For new wiki creations I would prefer if those were delayed but CC #DBA s
> > on the phabricator task to check with us.
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
(http://cscott.net)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Datacenter switchover and switchback

[Alexandros Kosiaris]

Reminder: The switchback is next week.
On Wed, Aug 29, 2018 at 8:28 PM Alexandros Kosiaris
 wrote:
>
> Hello everyone,
>
> This is to inform you that there will be a datacenter switchover and
> switchback on the next few weeks. The timeline's are
>
> Services: Tuesday, September 11th 2018 14:30 UTC
> Media storage/Swift: Tuesday, September 11th 2018 15:00 UTC
> Traffic: Tuesday, September 11th 2018 19:00 UTC
> MediaWiki: Wednesday, September 12th 2018: 14:00 UTC
>
> Switchback:
>
> Traffic: Wednesday, October 10th 2018 09:00 UTC
> MediaWiki: Wednesday, October 10th 2018: 14:00 UTC
> Services: Thursday, October 11th 2018 14:30 UTC
> Media storage/Swift: Thursday, October 11th 2018 15:00 UTC
>
> For the duration of the switchover (1 month), deployers are kindly
> requested to refrain from large db schema changes and avoid deploying
> any kind of new feature that requires creation of tables.
> There will be a train freeze in the week of Sept 10th and Oct 8th.
>
> The net effect of the switchover and switchback for volunteers is
> expected to be some minutes of inability to save an edit. For readers,
> everything will be as usual.
>
> The tracking task for interested parties is
> https://phabricator.wikimedia.org/T199073
>
> Regards,
>
> --
> Alexandros Kosiaris 



-- 
Alexandros Kosiaris 

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

Re: [Wikitech-l] Upcoming Search Platform Office Hours—October 3rd

[Trey Jones]

Last call! We're starting in just under an hour.

On Tue, Oct 2, 2018 at 11:07 AM, Trey Jones  wrote:

> Just a reminder that this is happening tomorrow, about 24 hours from now.
>
> Trey Jones
> Sr. Software Engineer, Search Platform
> Wikimedia Foundation
>
> On Thu, Sep 27, 2018 at 10:42 AM, Trey Jones  wrote:
>
>> The Search Platform Team
>>  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
>> 
>>
>> See you there!
>> —Trey
>>
>> Trey Jones
>> Sr. Software Engineer, Search Platform
>> Wikimedia Foundation
>>
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] problematic use of "Declined" in Phabricator

[Derk-Jan Hartman]

Another side effect of closing a ticket with Declined, is that it doesn't
show up in search (because it's closed and closed tickets are omitted by
default). But if the problem or desire for the feature still exists, it is
likely to be reported again by users via a new ticket and other people then
have to go duplicate hunting. So that creates more duplicates to weed
through.

And when I work on something, I often take a look at boards and see if
there is anything else in the same area that might need work, or I use the
tickets to get a feeling of the direction that people want us to go. When
declined is mixed with "we can't work on this right now", that makes it a
lot harder to do that as well.

So i think Stalled is better. The problem with that can be that such
tickets show up in workboards, which can create a lot of load in the
browser if there are a lot of tickets. If we would tag all of such tickets
with something like 'need-volunteer', a team could customise their work
board filter to exclude all tickets with that tag. Or simply exclude the
entire status, but then you cannot effectively use it within the team
either. We do have to make that need-volunteer tag somewhat better defined
in the bug lifecycle and the tag's description in that case. That tag
started out more as an "opportunities for volunteers". Alternative is a new
"no-resourcing" tag. or something.

DJ

On Wed, Oct 3, 2018 at 1:03 PM Amir Sarabadani  wrote:

> My two cents:
> I would personally make those type of tickets as "stalled", "stalled"
> basically for me means blocked and these type of tasks are blocked on human
> resources, some miracles might happen and we might end up having enough
> resources to unblock it but until that day it's stalled IMO.
>
> OTOH there are tickets that we don't have resources to work on it and we
> never will, imagine a ticket with title "Rewrite mediawiki", it sounds good
> as lots of part of it is old but we will never have such resource to do it.
> IMO, we should call it declined on grounds of not having resources. Same
> goes for "Every user should have a personal private wiki": We don't have
> hardware resources for that and probably never will.
>
> Best
>
> On Wed, Oct 3, 2018 at 7:27 AM Pine W  wrote:
>
> > I'm grateful for this largely civil and productive discussion. I'd like
> to
> > suggest that the multiple sub-topics being discussed here might be easier
> > to follow if the entire discussion is moved to a wiki talk page, such as
> on
> > MediaWiki.org. I am not attempting to halt discussion or to tell people
> to
> > stop writing to the mailing list; moving to a wiki talk page is just a
> > suggestion.
> >
> > Thanks,
> >
> > Pine
> > ( https://meta.wikimedia.org/wiki/User:Pine )
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] problematic use of "Declined" in Phabricator

[Amir Sarabadani]

My two cents:
I would personally make those type of tickets as "stalled", "stalled"
basically for me means blocked and these type of tasks are blocked on human
resources, some miracles might happen and we might end up having enough
resources to unblock it but until that day it's stalled IMO.

OTOH there are tickets that we don't have resources to work on it and we
never will, imagine a ticket with title "Rewrite mediawiki", it sounds good
as lots of part of it is old but we will never have such resource to do it.
IMO, we should call it declined on grounds of not having resources. Same
goes for "Every user should have a personal private wiki": We don't have
hardware resources for that and probably never will.

Best

On Wed, Oct 3, 2018 at 7:27 AM Pine W  wrote:

> I'm grateful for this largely civil and productive discussion. I'd like to
> suggest that the multiple sub-topics being discussed here might be easier
> to follow if the entire discussion is moved to a wiki talk page, such as on
> MediaWiki.org. I am not attempting to halt discussion or to tell people to
> stop writing to the mailing list; moving to a wiki talk page is just a
> suggestion.
>
> Thanks,
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l