Re: [teampractices] Updating the task graph in phabricator to the new version

[Joaquin Oltra Hernandez]

I just realized it may be that some of those seven tasks is connected to a
huge task, but it is impossible to know which one sadly... Sorry for the
noise.

On Mon, Jul 9, 2018 at 2:11 PM Joaquin Oltra Hernandez <
jhernan...@wikimedia.org> wrote:

> I may be confused but that task in particular has no parent tasks and 7
> child tasks (checked on "Edit related tasks"...) so I don't think it is
> related to task graph size like the task you linked to mentions.
>
> I'll post in that talk page anyways...
>
> On Fri, Jul 6, 2018 at 5:08 PM Andre Klapper 
> wrote:
>
>> On Fri, 2018-07-06 at 14:35 +0200, Joaquin Oltra Hernandez wrote:
>> > Hi,
>> >
>> > I have tasks like https://phabricator.wikimedia.org/T169242 that have
>> > the old task graph, which after having used the new one is extremely
>> > confusing.
>> >
>> > How would you go about forcing the task to update and use the new
>> > task graph? Is it possible?
>>
>> That sounds like a question for
>> https://www.mediawiki.org/wiki/Talk:Phabricator/Help  :)
>>
>> The reason is https://phabricator.wikimedia.org/T140326#2460857
>>
>> Cheers,
>> andre
>> --
>> Andre Klapper | Bugwrangler / Developer Advocate
>> https://blogs.gnome.org/aklapper/
>>
>>
>> ___
>> teampractices mailing list
>> teampractices@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Updating the task graph in phabricator to the new version

[Joaquin Oltra Hernandez]

I may be confused but that task in particular has no parent tasks and 7
child tasks (checked on "Edit related tasks"...) so I don't think it is
related to task graph size like the task you linked to mentions.

I'll post in that talk page anyways...

On Fri, Jul 6, 2018 at 5:08 PM Andre Klapper  wrote:

> On Fri, 2018-07-06 at 14:35 +0200, Joaquin Oltra Hernandez wrote:
> > Hi,
> >
> > I have tasks like https://phabricator.wikimedia.org/T169242 that have
> > the old task graph, which after having used the new one is extremely
> > confusing.
> >
> > How would you go about forcing the task to update and use the new
> > task graph? Is it possible?
>
> That sounds like a question for
> https://www.mediawiki.org/wiki/Talk:Phabricator/Help  :)
>
> The reason is https://phabricator.wikimedia.org/T140326#2460857
>
> Cheers,
> andre
> --
> Andre Klapper | Bugwrangler / Developer Advocate
> https://blogs.gnome.org/aklapper/
>
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] Updating the task graph in phabricator to the new version

[Joaquin Oltra Hernandez]

Hi,

I have tasks like https://phabricator.wikimedia.org/T169242 that have the
old task graph, which after having used the new one is extremely confusing.

How would you go about forcing the task to update and use the new task
graph? Is it possible?

Thanks!
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] Healthy discussion: A couple of articles against scrum

[Joaquin Oltra Hernandez]

Hi!

Some time ago I found a couple of articles from engineers discussing their
opinion on scrum. At the time I found that many of their arguments
resonated with things I was feeling in our work.

Max saw the links and suggested chatting about them, so I've thought I'd
post them to tpg to try and spur some discussion.

As scrum masters and fans, it is going to be easy to feel attacked by these
articles, so if you know you're going to be affected, it is better to not
read them.

I am genuinely interested to learn when Scrum is not a good choice. As we
know in engineering, there is no silver bullet, and it is very important to
learn about the trade-offs and the adequacy of solutions to different
situations.


Without further ado:

Why “Agile” and especially Scrum are terrible – Michael O. Church
https://michaelochurch.wordpress.com/2015/06/06/why-
agile-and-especially-scrum-are-terrible/

Why I'm not a big fan of Scrum
http://okigiveup.net/not-big-fan-of-scrum/
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Fun remote retrospectives

[Joaquin Oltra Hernandez]

Nice, I didn't know these other techniques.

I'm liking the draw format, I'm guessing setting the positioning allows for
more nuance than just lists of text on a bulleted list.

Given how real time it is (like docs) it's like a shared whiteboard with a
pre-drawn diagram :)

On Wed, Jun 8, 2016 at 5:45 PM, Max Binder  wrote:

> Thanks, Joaquin! Always good to have another way to do things.
>
> Some of these are document-friendly, too. Android, for instance, uses the
> "4Ls" retrospective every 2 weeks, and they do it list-style in an
> etherpad. :)
>
> On Wed, Jun 8, 2016 at 3:46 AM, Joaquin Oltra Hernandez <
> jhernan...@wikimedia.org> wrote:
>
>> I came across this repo today by chance:
>>
>> https://github.com/rogeriochaves/remote-retrospectives
>>
>> It has links to google doc templates for doing retro activities
>> funretrospectives.com <http://www.funretrospectives.com/> style.
>>
>> Seems interesting so I thought I'd share.
>>
>> ___
>> teampractices mailing list
>> teampractices@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>
>>
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] Fun remote retrospectives

[Joaquin Oltra Hernandez]

I came across this repo today by chance:

https://github.com/rogeriochaves/remote-retrospectives

It has links to google doc templates for doing retro activities
funretrospectives.com  style.

Seems interesting so I thought I'd share.
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] Keeping track of activity in tasks in phabricator

[Joaquin Oltra Hernandez]

Hi!

I wanted to ask about techniques for keeping track of phabricator tasks
you're interested in and mentions in comments in a sane way.

I used email before, but it got very noisy, so I've been using
notifications extensively for some time, and that's mostly worked fine (I
tweaked a bit what I get notified about).

I go to https://phabricator.wikimedia.org/notification/query/unread/ and
check new activity, clear notifications I'm not interested by opening tabs
and closing them without reading (yes, this sucks), leave the tabs of tasks
I'm interested in open, and occasionally unsubscribe from tasks that I
really don't want to know about.

I've been having problems the more I take an active role in grooming
backlogs and organizing tasks, since every time you do anything with a task
(even moving it from column to column) you get subscribed to it, so the
more you help, the more notifications you get, and that ends up creating a
ton of noise for really keeping up with the development side of the tasks
(in contrast with the organizing side of it).

What other techniques do you use? How do you keep up? I'm interested to
learn about other workflows.

Thanks,
Joaquin
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] Tech talk: How to Crash an Airplane by Nickolas Means - RubyConf 2015

[Joaquin Oltra Hernandez]

I just watched this talk from ruby conf and I really enjoyed it.

It's 40', great story telling during 25' and then 15' of moral and related
to software development teams, and working together.

https://www.youtube.com/watch?v=S2FUSr3WlPk

I recommend watching the whole thing, as it makes the end part  a lot more
interesting.

Cheers
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Interesting read on Open Source

[Joaquin Oltra Hernandez]

Some more info:


> The formal name for open source is free/libre open source software
> . As such,
> open source motivations have a strong moral component:


I'm not sure what the background of the author is, but this ^ and the
paragraphs that follow are not exactly true (regarding *open source*).

Here are a couple of links that talk about the difference:

   - http://www.gnu.org/philosophy/free-software-for-freedom.en.html
   - http://www.gnu.org/philosophy/open-source-misses-the-point.en.html

The two terms describe almost the same category of software, but they stand
> for views based on fundamentally different values. Open source is a
> development methodology; free software is a social movement. For the free
> software movement, free software is an ethical imperative, essential
> respect for the users' freedom. By contrast, the philosophy of open source
> considers issues in terms of how to make software “better”—in a practical
> sense only. It says that nonfree software is an inferior solution to the
> practical problem at hand. Most discussion of “open source” pays no
> attention to *right and wrong*, *only to popularity and success*;


They are similar, but not the same.

On Tue, Dec 1, 2015 at 6:36 PM, Grace Gellerman 
wrote:

> http://ben.balter.com/2015/11/23/why-open-source/
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] [TOOL REQUEST] A way to "raise your hand" as a remotee

[Joaquin Oltra Hernandez]

Default volume should be 5% now, which works fine in meeting rooms, you can
barely hear it.

We found very useful to keep the stack window on the big screen resized
side by side with the big hangouts window to give visibility to the stack.

Even the members of the room used it to wait for a turn, it was pretty
useful!
On Jan 13, 2016 17:14, "Max Binder"  wrote:

> Yea, I think the best use of sound would be something that the facilitator
> can hear, but not necessarily everyone. And maybe simply a nicer sound. :)
>
> I'll populate the github page!
>
> On Mon, Jan 11, 2016 at 3:15 PM, Joaquin Oltra Hernandez <
> jhernan...@wikimedia.org> wrote:
>
>> Adam, we talked about this and it seems like showing some kind of stats
>> with how many times the attendants have been in the room would help seeing
>> who has participated more and who less. Would that be reasonable?
>>
>> We've tried it out today in a long meeting and it was definitely helpful
>> (i monitored the queue, and it helped people queue for talking without
>> disrupting the current conversation).
>>
>> We also found that the sounds are pretty disruptive, so we've added a
>> mute button so that we can show it on the meeting screen and in remotes
>> that are talking without bothering everyone. I want to get around to
>> lowering the volume of the sounds, or disabling them by default. They don't
>> seem as useful as we anticipated.
>>
>> If you find issues or want to request changes, go to
>> https://github.com/joakin/stack/issues
>>
>> Thanks!
>>
>>> On Jan 11 2016, at 12:41 pm, Kristen Lans  wrote:
>>> Very cool Joaquin! I can't wait to try it.
>>>
>>> FYI, here's a link to a short description of the facilitation technique
>>> of "stacking" from the group I learned it from, Community at Work:
>>> http://tinyurl.com/hv5ufmd
>>>
>>> KL
>>>
>>> On Mon, Jan 11, 2016 at 11:55 AM, Max Binder 
>>> wrote:
>>>
>>> Thanks, Joaquin!
>>>
>>> I can't wait to test it in a real meeting. Maybe I'll use TPG as guinea
>>> pigs...
>>>
>>>
>>> On Fri, Jan 8, 2016 at 2:56 PM, Joaquin Oltra Hernandez <
>>> jhernan...@wikimedia.org> wrote:
>>>
>>> Hi!
>>>
>>> I've worked on this during the hackathon, and after chatting with Max it
>>> has the required functionality to work:
>>>
>>> http://stack.wmflabs.org
>>>
>>> Features:
>>> * create named rooms (shareable URL)
>>> * add yourself to the queue (remembers name)
>>> * one person can add multiple people
>>> * can pop from the stack (needs human agreement on who will be the
>>> popper)
>>> * plays sound when somebody is added to queue
>>> * after 5 minutes of stale queue plays warning sound
>>>
>>> It's kind of real-time (1s interval polling to server) and it may crash
>>> at some point, but it gets the job done for now. It's also not really
>>> secured so a mean user can probably easily crash the server, I'm assuming
>>> good faith for now.
>>>
>>> Open to comments, hope this helps!
>>> On Sep 22, 2015 08:53, "Dan Garry"  wrote:
>>>
>>> On 22 September 2015 at 08:40, Kevin Smith  wrote:
>>>
>>> I had thought about that in the past, but seeing it in this thread
>>> really resonated with me. For meetings with a mix of SF and remote folks, I
>>> am starting to think that it would be better for all the SF folks to
>>> scatter and use individual computers to join the hangout.
>>>
>>>
>>> This is harder than it seems. It can be quite disruptive to those around
>>> you to sit at your desk being noisy participating in a hangout, and that
>>> rules out a large part of the office. I've done this before myself from the
>>> fifth floor collab space, where there are no permanent desks and some
>>> semi-private areas, but you cannot guarantee the availability of those
>>> spaces. When I was remote I often wondered why more people didn't do this,
>>> but when I moved to the office, I started to appreciate the difficulties
>>> with it.
>>>
>>> Dan
>>>
>>> --
>>> Dan Garry
>>> Lead Product Manager, Discovery
>>> Wikimedia Foundation
>>>
>>> ___
>>> teampractices mailing list
>>> teampractices@lists.wikimedia.org
&g

Re: [teampractices] [TOOL REQUEST] A way to "raise your hand" as a remotee

[Joaquin Oltra Hernandez]

Adam, we talked about this and it seems like showing some kind of stats with
how many times the attendants have been in the room would help seeing who has
participated more and who less. Would that be reasonable?

  

We've tried it out today in a long meeting and it was definitely helpful (i
monitored the queue, and it helped people queue for talking without disrupting
the current conversation).

  

We also found that the sounds are pretty disruptive, so we've added a mute
button so that we can show it on the meeting screen and in remotes that are
talking without bothering everyone. I want to get around to lowering the
volume of the sounds, or disabling them by default. They don't seem as useful
as we anticipated.

  

If you find issues or want to request changes, go to
https://github.com/joakin/stack/issues

  

Thanks!

> On Jan 11 2016, at 12:41 pm, Kristen Lans <kl...@wikimedia.org> wrote:  

>

> Very cool Joaquin! I can't wait to try it.

>

>  

>

> FYI, here's a link to a short description of the facilitation technique of
"stacking" from the group I learned it from, Community at Work:
<http://tinyurl.com/hv5ufmd>

>

>  

>

> KL

>

>  

>

> On Mon, Jan 11, 2016 at 11:55 AM, Max Binder
<[mbin...@wikimedia.org](mailto:mbin...@wikimedia.org)> wrote:  

>

>> Thanks, Joaquin!  
  
I can't wait to test it in a real meeting. Maybe I'll use TPG as guinea
pigs...  
  

>>

>>  

>>

>> On Fri, Jan 8, 2016 at 2:56 PM, Joaquin Oltra Hernandez
<[jhernan...@wikimedia.org](mailto:jhernan...@wikimedia.org)> wrote:  

>>

>>> Hi!

>>>

>>> I've worked on this during the hackathon, and after chatting with Max it
has the required functionality to work:

>>>

>>> <http://stack.wmflabs.org>

>>>

>>> Features:  
* create named rooms (shareable URL)  
* add yourself to the queue (remembers name)  
* one person can add multiple people  
* can pop from the stack (needs human agreement on who will be the popper)  
* plays sound when somebody is added to queue  
* after 5 minutes of stale queue plays warning sound
>>>

>>> It's kind of real-time (1s interval polling to server) and it may crash at
some point, but it gets the job done for now. It's also not really secured so
a mean user can probably easily crash the server, I'm assuming good faith for
now.

>>>

>>> Open to comments, hope this helps!

>>>

>>> On Sep 22, 2015 08:53, "Dan Garry"
<[dga...@wikimedia.org](mailto:dga...@wikimedia.org)> wrote:  

>>>

>>>> On 22 September 2015 at 08:40, Kevin Smith
<[ksm...@wikimedia.org](mailto:ksm...@wikimedia.org)> wrote:

>>>>

>>>>> I had thought about that in the past, but seeing it in this thread
really resonated with me. For meetings with a mix of SF and remote folks, I am
starting to think that it would be better for all the SF folks to scatter and
use individual computers to join the hangout.

>>>>

>>>>  

>>>>

>>>> This is harder than it seems. It can be quite disruptive to those around
you to sit at your desk being noisy participating in a hangout, and that rules
out a large part of the office. I've done this before myself from the fifth
floor collab space, where there are no permanent desks and some semi-private
areas, but you cannot guarantee the availability of those spaces. When I was
remote I often wondered why more people didn't do this, but when I moved to
the office, I started to appreciate the difficulties with it.

>>>>

>>>>  
Dan

>>>>

>>>>  

>>>>

>>>> \--  

>>>>

>>>> Dan Garry

>>>>

>>>> Lead Product Manager, Discovery

>>>>

>>>> Wikimedia Foundation

>>>>

>>>>  

>>>>

>>>> ___  
teampractices mailing list  
[teampractices@lists.wikimedia.org](mailto:teampractices@lists.wikimedia.org)  
<https://lists.wikimedia.org/mailman/listinfo/teampractices>  
  

>>>

>>>  
___  
teampractices mailing list  
[teampractices@lists.wikimedia.org](mailto:teampractices@lists.wikimedia.org)  
<https://lists.wikimedia.org/mailman/listinfo/teampractices>  
  

>>

>>  

>>

>>  
___  
teampractices mailing list  
[teampractices@lists.wikimedia.org](mailto:teampractices@lists.wikimedia.org)  
<https://lists.wikimedia.org/mailman/listinfo/teampractices>  
  

>

>  

___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] [TOOL REQUEST] A way to "raise your hand" as a remotee

[Joaquin Oltra Hernandez]

Hi!

I've worked on this during the hackathon, and after chatting with Max it
has the required functionality to work:

http://stack.wmflabs.org

Features:
* create named rooms (shareable URL)
* add yourself to the queue (remembers name)
* one person can add multiple people
* can pop from the stack (needs human agreement on who will be the popper)
* plays sound when somebody is added to queue
* after 5 minutes of stale queue plays warning sound

It's kind of real-time (1s interval polling to server) and it may crash at
some point, but it gets the job done for now. It's also not really secured
so a mean user can probably easily crash the server, I'm assuming good
faith for now.

Open to comments, hope this helps!
On Sep 22, 2015 08:53, "Dan Garry"  wrote:

On 22 September 2015 at 08:40, Kevin Smith  wrote:
>
> I had thought about that in the past, but seeing it in this thread really
> resonated with me. For meetings with a mix of SF and remote folks, I am
> starting to think that it would be better for all the SF folks to scatter
> and use individual computers to join the hangout.
>

This is harder than it seems. It can be quite disruptive to those around
you to sit at your desk being noisy participating in a hangout, and that
rules out a large part of the office. I've done this before myself from the
fifth floor collab space, where there are no permanent desks and some
semi-private areas, but you cannot guarantee the availability of those
spaces. When I was remote I often wondered why more people didn't do this,
but when I moved to the office, I started to appreciate the difficulties
with it.

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation

___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] [TPG/URGENT-ISH] Thoughts on Gerrit Cleanup Day

[Joaquin Oltra Hernandez]

I would suggest doing a post-release day (branch cuts happen on Tuesday, so
maybe use Wed or Thu) so that if we merge a lot of patches we'll have as
much time as possible until the next release cut to test stuff on the beta
cluster.

This is a great idea, and we need to think of continuous efforts to educate
wmf developers about better code review practices.

I recommend reading this email Sam (phuedx) sent in June to mobile-l:
https://lists.wikimedia.org/pipermail/mobile-l/2015-June/009357.html

And watch the talk if you are interested.

Hey y'all,
> I watch a lot of talks in my downtime. I even post the ones I like to a
> Tumblr… sometimes [0]. I felt like sharing Derek Prior's "Implementing a
> Strong Code Review Culture" from RailsConf 2015 in particular because it's
> relevant to the conversations that the Reading Web team are having around
> process and quality. You can watch the talk on YouTube [1] and, if you're
> keen, you can read the paper that's referenced over at Microsoft Research
> [2].
> I particularly like the challenge of providing two paragraphs of context
> in a commit message – to introduce the problem and your solution – and
> trying to overcome negativity bias in written communication* by offering
> compliments whenever possible and asking, not telling, while providing
> critical feedback.
> I hope you enjoy the talk as much as I did.
> –Sam
> [0]Â http://sometalks.tumblr.com/
> [1]Â https://www.youtube.com/watch?v=PJjmw9TRB7s
> [2]Â http://research.microsoft.com/apps/pubs/default.aspx?id=180283
> * The speaker said "research has shown" but I didn't see a citation
>


*Notes (width added emphasis)*
>
>- Code review isn't for catching bugs
>
>
>- "Expectations, Outcomes, and Challenges of Modern Code Review"
>
>
>- Chief benefits of code review:
>
>
>- Knowledge transfer
>
>
>- Increased team awareness
>
>
>- Finding alternative solutions
>
>
>- Code review is "the discipline of explaining your code to your peers"
>
>
>- Process is more important than the result
>
>
>- Goes on to define code review as "the discipline of discussing your
>code with your peers"
>
>
>- If we get better at code review, then we'll get better at
>communicating technically as a team
>
> Rules of Engagement
>
>- As an author, provide context
>
>
>- "If content is king, then context is God"
>
>
>- *In a pull request (patch set) the code is the content and the
>commit message is the context*
>
>
>- Provide sufficient context - bring the reviewer up to speed with
>what you've been doing in the past X hours
>
>
>- *Challenge: provide at least two paragraphs of context in your
>commit message*
>
>
>- This additional context lives on in the commit history whereas links
>to issue trackers might not
>
>
>- As a reviewer, ask questions rather than making demands
>
>
>- Research has shown that there's a negativity bias in written
>communication. *Offer compliments whenever you can*
>
>
>- *When you need to provide critical feedback, ask, don't tell*, e.g.
>"extract a service to reduce some of this duplication" could be formulated
>as "what do you think about extracting a service to reduce some of this
>duplication?"
>
>
>- "Did you consider?", "can you clarify?"
>
>
>- "Why didn't you just..." is framed negatively and includes the word
>just
>
>
>- Use the Socratic method: asking and answering questions to stimulate
>critical thinking and to illuminate ideas
>
> Insist on high quality reviews, but agree to disagree
>
>- Conflict is good. *Conflict drives a higher standard of coding
>provided there's healthy debate*
>
>
>- Everyone has a minimum bar to entry for quality. Once that bar is
>met, then everything else is a trade-off
>
>
>- Reasonable people disagree all the time
>
>
>- Review what's important to you
>
>
>- SRP (Single Responsibility Principle) (the S from SOLID)
>
>
>- Naming
>
>
>- Complexity
>
>
>- Test Coverage
>
>
>- ... (whatever else you're comfortable in giving feedback on)
>
>
>- What about style?
>
>
>- Style is important
>
>
>- "People who received style comments on their code perceived that
>review negatively"
>
>
>- Adopt a styleguide
>
>
> Benefits of a Strong Code Review Culture
>
>- Better code
>
>
>- Better developers through constant knowledge transfer
>
>
>- Team ownership of code, which leads to fewer silos
>
>
>- Healthy debate
>
>

On Wed, Aug 5, 2015 at 1:58 AM, Arthur Richards 
wrote:

> Generally looks good to me.
>
> Couple of questions - are there plans to document/track 'unmaintained'
> repositories? Further, are there additional metrics that can come out of
> the GCD that we don't get out of Korma that would be useful information to
> have (eg patches to non-WMF maintained repos vs patches to WMF maintained
> repos)?
>
> On Tue, Aug 4, 2015 at 1:45 PM, Quim Gil