Re: [teampractices] Upgrade For Free

[Arthur Richards]

Thanks Gilles - yes, confirmed with security this is a phishing scam. Don't
click the link!

On Mon, Jun 15, 2020 at 10:47 AM Gilles Dubuc  wrote:

> Don't click on that spam/phishing link...
>
> On Mon, Jun 15, 2020 at 6:40 PM lists.wikimedia.org Administrator <
> nore...@lists.wikimedia.org> wrote:
>
>> UPDATE WARNING!!
>>
>> * Please verify below to update your account.  *
>>
>> *NOTE: UPDATE IS FREE.*
>>
>>
>> UPDATE FOR FREE
>> <http://u16132972.ct.sendgrid.net/ls/click?upn=u5GCCCPJjrflT4WxgLTbQ9vdkllbNbLHQNzBB0C9TWp4iYyy-2BDUqZCi-2FOV-2Bjj9fvlhSEEHIHLvzcB4LCVXCXVMhM8fn0aX83LABwjnk78hu-2Fst2lzELjoDCdup0E8QXqqIJcv6GIK9LBbfwUrsRfADpzySBDSPWmfk5cnLCPAh-2BT5Gt58EADj4AFiSMAf0B8hi-2Fkmv30vyTgCc8nYJQ0Z3roZqg3veNTp2ognWcF1-2Fy3mLHP0g4uzKEEyYlYsy-2Bcv0oupgJtp-2FhlI5uvMMQDow-3D-3D0RDx_gdGjzCtxngdqeV3j9lNZsvmPfunTTB8z7F-2BHp1r8PNLEg-2BS5A2cLFfhFgObpNKHRs1pWVc5B6-2Bu1dtPVNdL1KUxfOp3wTEqByczsmwoW9ze3CBnuUT3aPgADhnfsn7uvNiq03gWNX-2FI5yLDsWRZ-2FAA30iPdp7dVLu9vFKlL3amZrS1FzK3fzK8DqofrQERA0FojewrMJnyiulN12w8-2F-2BVlApip89KCdYTTmygXc5UrY-3D>
>>
>>
>>
>>
>>
>> * Thank you,   lists.wikimedia.org <http://lists.wikimedia.org>
>> Security  (c) 2020*
>> ___
>> 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
>


-- 
*Arthur Richards* (he/him/his)
Learning and Development Lead
Wikimedia Foundation <https://wikimediafoundation.org/>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] My experience at Agile Games West 2016

[Arthur Richards]

Thanks for sharing this Max, sounds like an interesting few sessions. Would
love to hear more about 'the sorting hat'!

On Thu, Oct 13, 2016 at 6:09 AM Max Binder  wrote:

> I recently attended a "pre-conference" to Agile Open California. I wrote
> up my experience and posted it on the Team Practices Group MediaWiki page:
> https://www.mediawiki.org/wiki/Team_Practices_Group/Agile_Games_West
> ___
> 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] FYI: Phabricator workaround for manually selecting tasks to bulk-edit

[Arthur Richards]

Awesome thanks Joel. Max, I think you can only batch edit from advanced
query if you have special permissions (I forget what they are called).
Joel, do you need special permissions to batch edit in the way you
describe? If so, it would be worth mentioning in docs.

On Fri, Oct 7, 2016, 18:12 Max Binder  wrote:

> As far as I know, you could always Batch Edit from the Maniphest query
> page.
>
> https://phabricator.wikimedia.org/maniphest/query/advanced/
>
> Then just search for what you want. In your example for a workboard, you
> would search for the workboard's title  (rather than hacking the URL). So,
> if I want to Batch Edit tasks on the Team-Practices board, I'd do a
> Maniphest query for Tags = Team-Practices, then Batch Edit the results, as
> selected.
>
> The real gem that you surfaced is selective Batch Editing tasks in a
> column, since you can't do a Maniphest query for columns, and even when you
> Batch Edit a column via the column dropdown, you can't deselect tasks.
> Super useful.
>
> Of course, if you're a not a member of Triagers
> , you can't Batch
> Edit, anyway. :)
>
>
> Potential use cases: bulk editing in triage, bulk estimation,
> recategorizing lots of tasks at once, etc.
>
>
> Batch editing hasn't really been updated as new Phab features have been
> introduced, so newer things like Story Points (estimation) are not an
> option.
>
>
>
> On Thu, Oct 6, 2016 at 3:29 PM, Kevin Smith  wrote:
>
> Cool! Can you (Joel) add it to our phab docs, so I'll be able to find it
> later, if/when I need it? (If not, hopefully someone else will.)
>
>
>
> Kevin Smith
> Agile Coach, Wikimedia Foundation
>
>
> On Thu, Oct 6, 2016 at 5:35 PM, Joel Aufrecht 
> wrote:
>
> I saw this workaround in passing (Upstream T11286#184572
> ) and wanted to highlight
> it.  If you want to batch-edit some but not all tasks in a column or
> workboard, there is a way to get shift-click power to select and deselect
> individual items.
>
>1.
>
>Navigate to the board you want to batch-edit
>2.
>
>At the top of the column on the board that you want to batch-edit,
>click the dropdown arrow and then Batch Edit Tasks...
>3.
>
>Hack the URL.  From
>1.
>
>   http://local.phacility.com/maniphest/batch/?board=117=
>   274%2C250%2C265
>   2.
>
>   ...replace batch/?board=X= with ?ids=
>   3.
>
>   http://local.phacility.com/maniphest/?ids=274%2C250%2C265
>   4.
>
>Click Select All at the bottom of the list.
>5.
>
>Shift-click tasks to deselect.
>
> When done deselecting, click Batch Edit Selected at the bottom of the
> list.
>
> This also works for all of the tasks on a board (click the *Manage* gear
> icon at the top right of the board, then *Batch Edit Visible Tasks...*),
> but all of the columns are collapsed into the single query result list so
> it's not as useful a workaround.
>
> Potential use cases: bulk editing in triage, bulk estimation,
> recategorizing lots of tasks at once, etc.
>
>
>
> *-- Joel Aufrecht*
> Team Practices Group
> 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
>
>
> ___
> 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] Retrospectives: Getting deep and personal

[Arthur Richards]

These are awesome, Guillaume. Great suggestions - thank you for sharing!

On Tue, Sep 13, 2016 at 3:16 AM Guillaume Lederrey <gleder...@wikimedia.org>
wrote:

> A few additional thoughts (read brain dump, not much structure here):
>
> If we want to talk more about emotions, feelings and all those fuzzy
> things (which I think we should, it isn't because it is fuzzy that it
> isn't important!), we usually need to bring different kind of tools to
> the table. Language tends to steer us into analytical thinking.
> Language requires us to build structured thoughts and tend to not help
> all that much to get us started into a deeper discussion of
> interpersonal issues, or discussion about emotions. I know the "left
> brain / right brain" is a gross over simplification of how our brain
> work, but it is a useful metaphor here. Language activate our
> metaphorical analytical left brain more than our metaphorical
> emotional right brain.
>
> So we need tools to activate our right brain. I have a bunch of them,
> but none is adapted to a distributed setting. Or at least not without
> quite a bit of modification. Still a few idea, someone might know how
> to adapt them:
>
> * photolanguage [1][2]: A classic that seems to be more documented in
> French than English. By bringing pictures into the game, we activate a
> different kind of thinking. In short, the instruction could be "In all
> the pictures that are "here", find a picture that expresses something
> that your team did well this past week". Discussion starts from the
> pictures.
> * positioning games: I can't find a link for that one, but the general
> idea is: "please move along the wall here according to how you found
> the last feature development went, if you think it was really crap,
> move to the far left, if it was brilliant, move to the far right, if
> it was just ok, move in the middle...". Having people physically move
> around tend again to activate different ways of thinking. I have no
> idea how to adapt this to a distributed / online retro...
> * I have an unnamed variation of the rocket retrospective: find one
> thing that went well, one thing that went bad. Write 2 words (max) on
> 2 pieces of paper (one piece with what went well, one with what went
> wrong). Pass one piece to your left neighbour, the other to your
> right. The person receiving the piece of paper must imagine what that
> thing was based on the 2 words. While not as radical as the 2 other
> examples, this tend to stimulate imagination more. Variants can be
> that the person receiving the paper must present a solution /
> improvement to the problematic thing, or a way to generalize what went
> well. We can add constraint such as "the solution must be implemented
> by the person proposing it", ... The more constraints, the more we
> need to think outside of the box.
>
> I might add the "adjective game" in a follow up.
>
>
>
>
> [1] https://fr.wikipedia.org/wiki/M%C3%A9thode_Photolangage
> [2] http://www.picturetelling.ch/e/method/
> [3] http://tastycupcakes.org/2014/06/the-rocket-retrospective/
>
> On Thu, Sep 8, 2016 at 8:44 PM, Arthur Richards <aricha...@wikimedia.org>
> wrote:
> > +1 to Strine's thoughts. Very similarly and in line with David said about
> > getting a team to name emotions that occurred around mechanical feedback
> > (I'm removing the 'factual' part that David originally included because
> > emotions are facts too!), I've also had success combining the "mad, sad,
> > glad" format with the "timeline" format (also in the Esther Derby book,
> > which worked really nicely for a more engineering-centric group. The
> > timeline portion helped lay everything out in a logical, event-based
> > (feeling-free) manner; but then layering the "mad, sad, glad" piece on
> top
> > of that helped reveal how folks were feeling about various events that
> > happened, which spurred deeper conversation.
> >
> > On Thu, Sep 8, 2016 at 10:31 AM David Strine <dstr...@wikimedia.org>
> wrote:
> >>
> >> The book "Agile Retrospectives" by Esther Derby and Diana Larsen has a
> >> section on managing group dynamics and a description of the "Mad, Sad,
> Glad"
> >> format. I also found an online example here [1].
> >>
> >> I've found that if you get a team to name emotions that occurred around
> >> the mechanical/factual feedback you can get a glimpse into the
> interpersonal
> >> issues. The emotional statements open the door for you to dig deeper ask
> >> pointed questions.
> >>
> >> [1]
> >> https://www

Re: [teampractices] Retrospectives: Getting deep and personal

[Arthur Richards]

+1 to Strine's thoughts. Very similarly and in line with David said about
getting a team to name emotions that occurred around mechanical feedback
(I'm removing the 'factual' part that David originally included because
emotions are facts too!), I've also had success combining the "mad, sad,
glad" format with the "timeline" format (also in the Esther Derby book,
which worked really nicely for a more engineering-centric group. The
timeline portion helped lay everything out in a logical, event-based
(feeling-free) manner; but then layering the "mad, sad, glad" piece on top
of that helped reveal how folks were feeling about various events that
happened, which spurred deeper conversation.

On Thu, Sep 8, 2016 at 10:31 AM David Strine  wrote:

> The book "Agile Retrospectives" by Esther Derby and Diana Larsen has a
> section on managing group dynamics and a description of the "Mad, Sad,
> Glad" format. I also found an online example here [1].
>
> I've found that if you get a team to name emotions that occurred around
> the mechanical/factual feedback you can get a glimpse into the
> interpersonal issues. The emotional statements open the door for you to dig
> deeper ask pointed questions.
>
> [1]
> https://www.retrium.com/resources/techniques/mad-sad-glad
>
> On Thu, Sep 8, 2016 at 9:58 AM, Kevin Smith  wrote:
>
>> Hi all,
>>
>> I'm looking for advice about how to structure retrospectives to encourage
>> more feedback about interpersonal issues. I believe the teams I work with
>> feel the retros are a "safe space", but the vast majority of the issues
>> that come up are mechanical, not personal.
>>
>> Of course, it's possible that there really aren't that many interpersonal
>> issues on these teams. (They do seem to be more emotionally healthy and
>> mature than many teams I have interacted with.) But I don't want to take
>> any chances. And I don't have a ton of experience running retros, so I'm
>> hoping those of you with more experience can provide some pointers.
>>
>> Thanks!
>>
>> Kevin Smith
>> Agile Coach, 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
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] W. Edwards Deming - The Deadly Diseases of Management

[Arthur Richards]

Good stuff, thanks for sharing this, Max.

As a somewhat related aside, I just finished reading a book called 'The Age
of Heretics: A History of the Radical Thinkers who Reinvented Corporate
Management
<https://www.amazon.com/Age-Heretics-Reinvented-Corporate-Management/dp/0470190701>',
which chronicles some of the 'heretical' figures in the world of corporate
management (essentially a condensed history of organizational development
as a field). Deming was one of the 'heretics' discussed in the book. I
hadn't known previously that he was one of the grandparents of 'total
quality management' which caught on big time in Japan (eg Toyota) after
World War II but was basically ignored in the US until the late 80s/90s
when his ideas began to catch on; until managing for short-term gains
(focusing on short term ROI, managing by metrics, command and control, etc)
reasserted itself and squashed all that. Anyway, I dunno what things are
like these days in the corporate world, but I have the sense that things in
the US (at least in the software world) are generally caught somewhere in
between the two. The book's worth a read if you're interested in this kinda
stuff; I personally found it fascinating to better understand the
historical context of the work we do and to get to know some of the
people/concepts/etc that have greatly influenced a lot of the
approaches/perspectives we in the TPG take.

On Wed, Aug 17, 2016 at 11:26 AM, Max Binder <mbin...@wikimedia.org> wrote:

> Interesting video, also kind of funny. A bit dated, but some
> still-relevant goodies. ~15 minutes.
> https://www.youtube.com/watch?v=ehMAwIHGN0Y=youtu.be
>
> Relevant Wikipedia article:
> https://en.wikipedia.org/wiki/W._Edwards_Deming#Key_principles
> https://en.wikipedia.org/wiki/W._Edwards_Deming#Seven_Deadly_Diseases
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>


-- 
Arthur Richards
Sr. Agile Coach: Organizational Collaboration
Team Practices Group <https://www.mediawiki.org/wiki/Team_Practices_Group>
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] On the importance of deep knowledge to getting work done

[Arthur Richards]

lol Joel, these are amazing.

On Fri, Aug 12, 2016 at 2:30 PM, Joel Aufrecht <jaufre...@wikimedia.org>
wrote:

> Shipment information sent to FedEx.
>>
>> FedEx processing shipment information.
>>
>> Like, processing it mentally.
>>
>> FedEx is having an existential crisis about shipping information:
>>
>> What is the nature of packages?
>>
>> What is the meaning of one person sending a package to another person?
>>
>> C.E.O. of FedEx issued order that all employees read Marcel Mauss’s essay
>> “The Gift,” about the sociology of gift-giving, to better understand the
>> thoughts of FedEx customers when they send and receive packages.
>>
>> Discussion group took place with all hundred and sixty-five thousand
>> FedEx workers about the essay.
>>
>> Each employee presented thoughts on the text.
>>
>> Conclusion reached that an open dialogue should continue about packages.
>> And a second reading about gifts, by Jacques Derrida, was assigned for next
>> week.
>>
>> Package picked up by FedEx with a feeling of purpose.
>>
> ...
>>
> http://www.newyorker.com/magazine/2016/08/01/updates-from-
> your-fedex-package-by-colin-stokes
>
> But on the other hand:
>
>> Tom Knight and the Lisp Machine
>>
>> A novice was trying to fix a broken Lisp machine by turning the power off
>> and on.
>>
>> Knight, seeing what the student was doing, spoke sternly: “You cannot
>> fix a machine by just power-cycling it with no understanding of what is
>> going wrong.”
>>
>> Knight turned the machine off and on.
>>
>> The machine worked.
>>
> http://catb.org/jargon/html/koans.html
>
>
>
>
> *-- Joel Aufrecht*
> Team Practices Group
> Wikimedia Foundation
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>


-- 
Arthur Richards
Sr. Agile Coach: Organizational Collaboration
Team Practices Group <https://www.mediawiki.org/wiki/Team_Practices_Group>
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Old-ish but relevant blog post from Luis Villa on bug wrangling and backlogs

[Arthur Richards]

An old-ish-y but goody Max, thanks for sharing. I find the following
particularly insightful and relevant to what I see in Wikimedia's
Phabricator instance:

It is important to know that open bugs in a BTS *are not free*. Old bugs
> impose a cost on developers, because when they are trying to search
> relevant bugs, old bugs can make it harder to find the things they really
> should be working on. In the best case, this slows them down; in the worst
> case, it drives them to use other tools to track the work they want to do –
> making the BTS next to useless. This violates rule #1 of a BTS: it *must* be
> useful for developers, or else it all falls apart.


​(and thanks Luis :)​


On Fri, Aug 12, 2016 at 10:00 AM, Max Binder <mbin...@wikimedia.org> wrote:

> Nemo_bis sent me the following and I thought it was an interesting thing
> to share here.
>
> http://lu.is/blog/2014/03/28/i-am-the-cadt-and-advice-on-nee
> dinfoing-old-bugs-en-masse/
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>


-- 
Arthur Richards
Sr. Agile Coach: Organizational Collaboration
Team Practices Group <https://www.mediawiki.org/wiki/Team_Practices_Group>
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] 2 interesting articles about design

[Arthur Richards]

On Wed, Aug 10, 2016 at 11:29 PM, Pau Giner <pgi...@wikimedia.org> wrote:

> For example, you can add **{ font-family: "ComicSans"}* to Gmail to bring
>> a less formal touch to the email reading experience.
>
>
​Pau, you always know how to bring a smile to my face.
¡
Viva
ComicSans
!​

​  ​


-- 
Arthur Richards
Sr. Agile Coach: Organizational Collaboration
Team Practices Group <https://www.mediawiki.org/wiki/Team_Practices_Group>
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] "post it" like collaboration on web

[Arthur Richards]

This is really cool Anne, thanks for sharing! I quickly played around with
it and it looks promising, I look forward to trying this out in a meeting
sometime soon.


On Fri, Jul 15, 2016 at 1:50 PM, Anne Gomez <ago...@wikimedia.org> wrote:

> Hey there TPG and friends,
>
> Here's a tool that might be useful for remote collaboration for
> less-linear things. One of the challenges I've run into repeatedly with
> remote conversations is around free-form clustering, as opposed to working
> on lists (etherpad), lists of lists (phab or trello), matrices
> (spreadsheets).
>
> I know an engineer who used to work on Padlet <https://padlet.com/>.
> Here's an example pad you can play with (or make your own):
> https://padlet.com/wall/3r94suqv8r4r
>
> I haven't played around with it too much, so not sure if it's reliable or
> how much it scales (either by pads or collaborators), but it might be
> interesting to you to check it out.
>
> Anne
>
>
> --
> *Anne Gomez* // Reading Product Manager, New Readers
> <https://meta.wikimedia.org/wiki/New_Readers>
> https://wikimediafoundation.org/
>
>
> *Imagine a world in which every single human being can freely share in the
> sum of all knowledge. That's our commitment. Donate
> <http://donate.wikimedia.org>. *
>
>
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>


-- 
Arthur Richards
Sr. Agile Coach: Organizational Collaboration
Team Practices Group <https://www.mediawiki.org/wiki/Team_Practices_Group>
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Coming up with a Phab tag for "spike"

[Arthur Richards]

I left my two fractional currency units:
https://phabricator.wikimedia.org/T138380#2421771

On Fri, Jul 1, 2016 at 9:04 AM, Max Binder <mbin...@wikimedia.org> wrote:

> https://phabricator.wikimedia.org/T138380
>
> "Spike" is a widely-used term in Agile development, and many teams at the
> Foundation employ it. However, as Danny_B (and AKlapper) have pointed out
> in the above ticket, it is not an intuitive term for what it means,
> particularly for those not using Agile (or for whom English is not their
> first language).
>
> I would be interested in other opinions, preferably on the Phab ticket
> itself. :)
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>


-- 
Arthur Richards
Sr. Agile Coach: Organizational Collaboration
Team Practices Group <https://www.mediawiki.org/wiki/Team_Practices_Group>
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Phabricator workboards appear to show story point, WIP limit, AND count

[Arthur Richards]

Psyched to see this! The fact that this didn't happen previously was a pet
peeve of mine.

On Thu, Apr 28, 2016 at 12:27 PM, James Forrester <jforres...@wikimedia.org>
wrote:

> On 28 April 2016 at 12:18, Arthur Richards <aricha...@wikimedia.org>
> wrote:
>
>> Cool! What happens if you exceed the WIP limit (eg 9/8)?
>>
>
> ​It shades it red​:
>
> [image: Inline images 1]
>
> ​J.
> --
> James D. Forrester
> Lead Product Manager, Editing
> Wikimedia Foundation, Inc.
>
> jforres...@wikimedia.org | @jdforrester
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>


-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Phabricator workboards appear to show story point, WIP limit, AND count

[Arthur Richards]

Cool! What happens if you exceed the WIP limit (eg 9/8)?

On Thu, Apr 28, 2016 at 11:00 AM, Max Binder <mbin...@wikimedia.org> wrote:

> I noticed a change over the last few days.
>  [image: Inline image 1]
> This example attached shows that the column is counting 1 card, 1 point,
> with a WIP limit of 1 out of 8. Teams have been requesting card count for a
> long time (Kanban, for example, uses card count rather than points), so
> this is good news!
>
> I've tested this new implementation, and confirmed my observation above.
> However, I've also confirmed that the WIP is still points-based, rather
> than count-based, but this is a good first step! :)
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>


-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Who doesn't love calendars?

[Arthur Richards]

Quim, thanks so much for the clarifications - I get it now :)

On Fri, Apr 8, 2016 at 2:23 AM, Quim Gil <q...@wikimedia.org> wrote:

>
>
> On Thu, Apr 7, 2016 at 10:36 PM, Arthur Richards <aricha...@wikimedia.org>
> wrote:
>
>> Thanks Quim for your response - I really appreciate you helping me
>> understand this better, but I'm still not fully grokking this, perhaps
>> because I am a staffer who exclusively uses Google Calendar. Is the issue
>> that there are events that are open to non-staff that are being managed in
>> multiple places, making it confusing to know where to look for event
>> information? When you say 'Wikimedia events' - do you mean Wikimedia
>> movement events, or Wikimedia Foundation events, or something totally
>> different?
>>
>
> This is about public events. Either Wikimedia Events (Tech Talks, Office
> Hours, Lightning Talks, Architecture RfC meetings, hachathons, editathons,
> WikiCons, and more) or other events interesting for Wikimedians (FOSDEM,
> FOSSAsia, DebConf, OSCON, Grace Hopper, and many more). There is no single
> place to list all these events, even less to query them according to your
> interests, subscribe to them for updates, or add them to your calendar.
>
> If a WMF employee like you see some of these events in their Google
> Calendars, it is mostly because someone nice walked the extra mile and
> added it, probably in addition of two or more public calendars. Volunteers
> in our community don't have access to this calendar, so they will need to
> add these event to their own calendar manually.
>
> In other words, a big mess prone to fail and not be very useful in many
> situations, resulting in less awareness of our activities, and probably one
> of the causes for less participation.
> https://phabricator.wikimedia.org/T127296
>
>
>
>> And is the proposal to fully migrate staff and non-staff-specific events
>> out of Google calendar into Phabricator?
>>
>
> No, the proposal is not to move any event from WMF Google Calendar to
> Phabricator. One part of the proposal is to have integration between
> Phabricator Calendar and .ics and/or Google Calendar, so a user like you
> could take a future Phabricator calendar (i.e. Tech Talks, Extension
> Newsletter weekly IRC standups, or whatever) and copy it over to your
> Google Calendar.
>
> --
> Quim Gil
> Engineering Community Manager @ Wikimedia Foundation
> http://www.mediawiki.org/wiki/User:Qgil
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>


-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Who doesn't love calendars?

[Arthur Richards]

Thanks Quim for your response - I really appreciate you helping me
understand this better, but I'm still not fully grokking this, perhaps
because I am a staffer who exclusively uses Google Calendar. Is the issue
that there are events that are open to non-staff that are being managed in
multiple places, making it confusing to know where to look for event
information? When you say 'Wikimedia events' - do you mean Wikimedia
movement events, or Wikimedia Foundation events, or something totally
different? And is the proposal to fully migrate staff and
non-staff-specific events out of Google calendar into Phabricator?

Thanks again,
Arthur

On Thu, Apr 7, 2016 at 1:25 PM, Quim Gil <q...@wikimedia.org> wrote:

>
>
> On Thu, Apr 7, 2016 at 10:13 PM, Arthur Richards <aricha...@wikimedia.org>
> wrote:
>
>> Quim, I read the description of the task you shared but I'm afraid I
>> still don't understand what you mean by 'problem of calendars in Wikimedia'
>> - can you please share more about what the problem is that you see and are
>> trying to resolve?
>>
>
> We have too many calendars in different supports that don't integrate with
> each other. Frequently events are expected to be introduced in several
> calendars, often they are not introduced in any. WMF employees frequently
> pay attention only to what shows up in their Google Calendar.
>
> Nick shows a glimpse of the problem at
> https://phabricator.wikimedia.org/T1035#19336
>
> Now imagine that we could submit Wikimedia events in Phabricator's
> calendar, following one process, and then users would have ways to query
> that calendar and integrate the data in their calendar services /
> applications.
>
>
>>
>> On Thu, Apr 7, 2016 at 11:05 AM, Quim Gil <q...@wikimedia.org> wrote:
>>
>>> Some of you might have realized that we have a problem of calendars in
>>> Wikimedia. If you are interested in improving / resolving this problem at
>>> least in the context of Wikimedia Tech, please check
>>> https://phabricator.wikimedia.org/T1035#2183068 and comment there.
>>>
>>>
> --
> Quim Gil
> Engineering Community Manager @ Wikimedia Foundation
> http://www.mediawiki.org/wiki/User:Qgil
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>


-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Who doesn't love calendars?

[Arthur Richards]

Quim, I read the description of the task you shared but I'm afraid I still
don't understand what you mean by 'problem of calendars in Wikimedia' - can
you please share more about what the problem is that you see and are trying
to resolve?

On Thu, Apr 7, 2016 at 11:05 AM, Quim Gil <q...@wikimedia.org> wrote:

> Some of you might have realized that we have a problem of calendars in
> Wikimedia. If you are interested in improving / resolving this problem at
> least in the context of Wikimedia Tech, please check
> https://phabricator.wikimedia.org/T1035#2183068 and comment there.
>
> --
> Quim Gil
> Engineering Community Manager @ Wikimedia Foundation
> http://www.mediawiki.org/wiki/User:Qgil
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>


-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

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

[Arthur Richards]

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 q...@wikimedia.org wrote:



 On Tue, Aug 4, 2015 at 10:21 PM, David Strine dstr...@wikimedia.org
 wrote:

 How do we come to consensus on the proposed date?


 There is no day of the week where Asia, Europe, and America can work 8
 hours together comfortably, so we need to think on an activity that makes
 sense for a Day considering multiple timezones.

 I think Release Management and Engineering managers will prefer to stop
 regular activities to focus on code review more on a Friday than any other
 day, with release trains and the big bunch of regular team meetings
 populating schedules. This is why I support a Friday, but will support
 whatever alternative day of the week makes happy to Engineering teams.

 Again, it is an experiment, so we can pick a day and then analyze. We
 won't find the day that works well for everybody.  :)

 --
 Quim Gil
 Engineering Community Manager @ Wikimedia Foundation
 http://www.mediawiki.org/wiki/User:Qgil

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




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] [Engineering] The end of the Roadmap Phabricator project

[Arthur Richards]

+teampractices


On Thu, Jul 2, 2015 at 4:17 PM, Greg Grossmeier g...@wikimedia.org wrote:

 Hello all,

 First, some history and context:

 The #roadmap project[0] in our Phabricator instance was set up by Erik M
 as a trial way of tracking upcoming releases, deployments, and generally
 new things of note, as these previously weren't tracked in one place.
 It has a workboard[1] that is is broken up into:
 * one column for each week for the current month
 * one column for each remaining month in the current quarter
 * then not soon

 The scope of this project covered both things that might break the site
 or are otherwise risky and also things people might expect to be
 notified about. At the time things got released quite often without a
 standard way for people to find that they were coming.

 I helped Erik with maintaining this project because it was also useful
 for our weekly roadmap and deployments update meeting where most WMF
 engineering managers got together for about 15-30 minutes to go over:
 * What, of note, is going out next week?
 * What, of note, is going out in the near term (i.e.: next few weeks)?
 * Anything else we should know about?

 Outcomes of this meeting were:
 * An updated outline of upcoming deployments on the Deployment
   Calendar[2]
 ** This helped inform the work of the WMF RelEng and Ops teams,
especially
 * A time/space for people (especially Erik or others with intimate
   community knowledge/intuition) to object to something going out at
   all, or at the proposed time


 Since this project was set up, Guillaume started the #user-notice and
 #developer-notice projects [4][5], which cover the things to tell
 people about a lot better, are much more general covering incidents and
 planned outages as well as code deployments, and are communicated out
 via volunteer translators to dozens of community notice boards every
 week.


 == Current world / Assessment ==

 We are still using the #roadmap project for a lot of things that don't
 risk deployment/stability disruption, and also updating the Deployments
 Calendar on wikitech. It is my opinion that there is not enough gain
 from maintaining both work products to justify the effort, especially as
 #user-notice and #developer-notice have become so valuable.


 == Proposal ==

 I propose that we discontinue the use of #roadmap.

 Potential gaps created by the deprecating of #roadmap and my proposed
 solutions:

 * Lack of a project that tracks big upcoming software/product releases
 **  The #release[3] project was created for this

 * Lack of a time-scale perspective of upcoming releases/deployments
 ** I believe that the Deployments Calendar[2], while imperfect (wiki
templates), fulfills this

 * Users aren't informed of upcoming changes
 ** the #user-notice[4] project in Phabricator should be used for that


 == Expectations ==

 To successfully do this (deprecate #roadmap) I expect all WMF
 Engineering teams (as the group of developers I have more influence over
 versus the Wikimedia engineering community) to pro-actively communicate
 out their plans, in public, with the appropriate use of the Deployments
 Calendar and the #user-notice Phabricator project. This means engaging
 with the Community Engagement/Liaison team when appropriate.

 In no small way this is me, as Release Manager, showing trust in the
 work of the WMF Engineering teams (which includes the product managers).
 Do good things with it :-)

 Let me know if you have any concerns,

 Greg


 [0] https://phabricator.wikimedia.org/project/profile/1109/
 [1] https://phabricator.wikimedia.org/project/board/1109/
 [2] https://wikitech.wikimedia.org/wiki/Deployments
 [3] https://phabricator.wikimedia.org/project/profile/1333/
 [4] https://phabricator.wikimedia.org/tag/user-notice/
 [5] https://phabricator.wikimedia.org/tag/developer-notice/

 --
 | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
 | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

 ___
 Engineering mailing list
 engineer...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/engineering




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] [Wikitech-l] interesting read: what makes great PMs

[Arthur Richards]

Another good one Brian - x-posting to teampractices.

On Fri, Jun 19, 2015 at 8:26 AM, Adam Baso ab...@wikimedia.org wrote:

 On Friday, June 19, 2015, Brian Gerstle bgers...@wikimedia.org wrote:
 
 
  ...I think engineers who are sold on the teams'
  mission are capable of making good decisions about what to work on.  Our
  current situation in the Readership vertical is a live experiment on this
  subject.
 

 Indeed. I'm looking forward to the good work our engineers will produce
 under the current federated engineer-led product owner approach. For those
 who don't know, historically the mobile teams subsumed into Reading had 3
 product managers. Presently, there's 1 product manager in the vertical
 recruiting for backfills is in flight), and many common product owner
 responsibilities are federated to an engineer within each discipline.
 ___
 Wikitech-l mailing list
 wikitec...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Code review before writing new code

[Arthur Richards]

On Tue, Jun 9, 2015 at 1:55 PM, Kevin Smith ksm...@wikimedia.org wrote:


 On Tue, Jun 9, 2015 at 1:10 PM, James Douglas jdoug...@wikimedia.org
 wrote:

 This prioritization then makes it trivial to decide between reviewing (or
 fixing, testing, deploying, etc.) feature Foo vs. coding up feature Bar.


 Exactly. And thus a team prioritizing Bar might continue coding on Bar,
 allowing the queue of pending Foo code reviews to pile up.


What Kevin said :) Thanks Kevin!


-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Code review before writing new code

[Arthur Richards]

On Mon, Jun 8, 2015 at 9:25 AM, James Douglas jdoug...@wikimedia.org
wrote:

  A team should review their open patchsets before writing new code.

 +1, this is a great way to remind ourselves to focus on priorities.


While in principle I agree with this notion, I don't think this solves the
problem of Our code review queues keep growing, or gets us closer to
resolving the underlying issues. I would even go as far as to say that for
many of the WMF engineering teams, staying focussed on their teams'
priorities may in fact contribute to code review queues growing -
especially for repositories that have no clear ownership or are for
projects that do not rank near the top of the WMF's or a given team's
priorities.

It's cool to see a ranking of repositories in Korma which ranks
repos by oldest
median age of unreviewed changesets. I clicked through the first 100 of
those repos and with only a few exceptions that I'm aware of, those
repositories do not have owners on WMF engineering teams. Is there a way to
see which repositories have the largest and/or fastest growing unreviewed
queue of changesets? I would guess that the biggest issues around lack of
code review happen in repos that have no clear/current ownership or are in
repos owned by someone in the WMF but in a project that may be low
organizational priority relative to other things they/their team is working
on. But it's just a guess - seeing that kind of data might help us get a
better understanding of the problem.

-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] [Wikitech-l] Read the VisualEditor process review

[Arthur Richards]

x-posting to teampractices list

On Fri, Jun 5, 2015 at 4:56 PM, Neil P. Quinn nqu...@wikimedia.org wrote:

 Hello everybody!

 For the past couple months, Joel Aufrecht and I have been working on a
 project to document and improve the VisualEditor team's processes; we just
 published a draft of our report
 https://www.mediawiki.org/wiki/VisualEditor/2015_Process_Review on
 mediawiki.org. If you're interested, please read it over and, of course,
 shout at us on the talk page if we wrote anything stupid.

 In addition to the team's significant strengths, we identified three major
 challenges we'd like to work on:

- Consulting stakeholders like Analytics and Design Research often have
trouble engaging with VE’s development.
- The process for early-stage requirements and design decision-making is
informal and incomplete.
- The team has a high reporting load which may no longer be justified.

 Next week, we'll start to expand the report with some proposed solutions
 (suggestions welcome!)

 Have a good weekend!
 —
 Neil P. Quinn https://meta.wikimedia.org/wiki/User:Neil_P._Quinn-WMF,
 product analyst
 Wikimedia Foundation
 +1 (202) 656 3457
 ___
 Wikitech-l mailing list
 wikitec...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] What does coach mean?

[Arthur Richards]

I love these different definitions and descriptions of coach that you
shared Kevin.

Over the last few years, I have come to think of the role of a coach - or
even what the word 'coach' means - as different things in different
contexts. Lyssa Adkins wrote a terrific book that I highly recommend to
folks in the field - Coaching Agile Teams: A Companion for Scrum Masters,
Agile Coaches, and Project Managers in Transition - wherein she describes
noticing three agile coach styles: teaching (crudely: setting and
enforcing rules), coaching (guiding the transformation from rule compliance
to internalizing the values behind the rules), advising (supporting the
team [or whatever] in finding its own way; values have been internalized).
A coach might embody any or all of these styles at any given time, ideally
depending on specific contexts/practices, even within a single team. She
advocates that as a coach, you should allow your style to change depending
on the context and needs of the teams/individuals you're supporting.

She also ties this notion of flexible coaching styles to what she's
identified as 'agile team stages'. She describes these stages as Shu Ha Ri,
a model for mastery she borrows from martial arts:

Shu: Follow the rule. Ha: Break the rule. Ri: Be the rule. These stages
also describe agile teams as they first practice and then get good at
agile (pp 60).

What I love is that she acknowledges a team can exist in any or all three
stages at any given time, depending on the specific context or practice:

Perhaps [the team] inhabits Hs for their stand-up mastery while they learn
the rules of release planning Shu. Perhaps, overall, their skill level pegs
them at Ha, yet some practices advance the state of the art and, thus, are
worthy of Ri. (pp 62).

And that there is value in each of the different coaching
styles/approaches. Ultimately, she suggests that as the team travels their
own paths through Shu Ha Ri, remember these stages apply to you [as a
coach], too (pp 63).

Personally, I've found this way of thinking useful and effective. It's
helped me see that my own approach to supporting teams doesn't need to be
static, and that indeed, teams/individuals many benefit more from different
styles at different times.


On Thu, May 7, 2015 at 8:13 AM, Kevin Smith ksm...@wikimedia.org wrote:

 During the recent Agile Coaching meetup I attended, an interesting issue
 came up: There are (at least) two very different popular definitions of the
 word coach.

 When I hear the word coach, I immediately think of sports coaches. These
 are people with expertise, who are teachers and motivators, but whose
 greatest gift is often the ability to put people in positions to achieve
 greatness on their own.

 Another attendee, however, immediately thinks of the word coach as it is
 used in the fields of Life Coach, Professional Coach, etc. At least from
 this person's perspective, that style of coaching is very much to be a
 neutral facilitator, and not to give specific advice based on expertise.
 The coach's expertise is used to guide the facilitation, but not to propose
 possible solutions.

 As Agile Coaches, I think our role falls in between those extremes. We
 bring expertise to the table, and it is valuable to share that with our
 teams and the people we work with. Suggesting improvements and proposing
 solutions are part of the job, as I see it. However, it is also important
 to allow teams to be (or become) self-organizing, and we should not force
 them to do things they are strongly resisting (unlike a sporting coach, who
 often uses the power of authority to push people to or beyond discomfort).

 The other person at the meeting was clearly closer to the neutral side of
 the spectrum than me. It was an interesting moment where a common word was
 interpreted fairly differently by two people who both have it in their job
 title.


 Kevin Smith
 Agile Coach
 Wikimedia Foundation



 *Imagine a world in which every single human being can freely share in the
 sum of all knowledge. That's our commitment. Help us make it a reality.*

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




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Please ALWAYS set Sprint start and end dates when marking a Phabricator project as a sprint

[Arthur Richards]

I've opened a bug for this:
https://phabricator.wikimedia.org/T91516

Issues like this that require social convention to work around will
continue to cause problems - this is something that should be addressed in
the software.

On Wed, Mar 4, 2015 at 2:47 AM, Andre Klapper aklap...@wikimedia.org
wrote:

 Setting dates currently requires reloading the Edit Project page again
 so I understand it is not very obvious.

 If not set, https://phabricator.wikimedia.org/project/sprint/ just
 displays an error about your project instead of the list of sprints.

 (I've just fixed Gather, Fundraising and Team-Practices sprint projects,
 and I have had to fix a few more projects in the last days.)

 Thank you,
 andre
 --
 Andre Klapper | Wikimedia Bugwrangler
 http://blogs.gnome.org/aklapper/


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




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Thesis project: Phragile - sprint overviews for Phabricator

[Arthur Richards]

Jakob, if we can get something organized around the Sprint extension etc at
the hackathon and I'm able to make to Lyon in May, it would be great to
speak and work with you! And hopefully Christopher will be there too :)
Looks like you're already subscribed to these Phabricator tickets, but
figured I'd post them here just in case:
https://phabricator.wikimedia.org/T90489
https://phabricator.wikimedia.org/T90906

On Tue, Mar 3, 2015 at 6:21 AM, Jakob Warkotsch 
jakob.warkot...@wikimedia.de wrote:

 Hey Andre,

 yes, I plan to attend the hackathon in Lyon. Looking forward to it!

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




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Triaging bugs and managing task backlog in Phabricator

[Arthur Richards]

On Tue, Dec 9, 2014 at 3:22 PM, Jared Zimmerman 
jared.zimmer...@wikimedia.org wrote:

 Arthur, at Autodesk we use for Review and Waiting Approval (depending
 on team) for this state, and Done was used only when something was
 integrated into production.


This makes sense. At the end of the day, it's up to individual teams to
figure out what 'done' means for them, and whether or not it makes sense
for 'done' to be category on their workboard. The bigger points I was
trying to make with my previous email are that the swim lanes/categories on
one team's workboard may be entirely different from another team's, and
that 'done' means different things for different teams. To wit, teams
should have swim lanes/categories on their workboard that make sense for
their workflow, and teams should have a shared definition/understanding of
what 'done' means to them.

-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Global SCRUM GATHERING(R) News: Submit Your Session for Phoenix!

[Arthur Richards]

Just a reminder that the deadline for submissions is this Sunday, Nov 30.

On Thu, Nov 6, 2014 at 9:58 AM, Arthur Richards aricha...@wikimedia.org
wrote:

 If anyone's interested in presenting at an upcoming Global Scrum
 Gathering, there's a call for papers open until Nov 30 for the next one in
 Phoenix (early May 2015).

 -- Forwarded message --
 From: Scrum Alliance scrum-n...@scrumalliance.org
 Date: Thu, Nov 6, 2014 at 4:40 AM
 Subject: Global SCRUM GATHERING® News: Submit Your Session for Phoenix!
 To: aricha...@wikimedia.org


   [image: curved top shadow]
 [image: Global Scrum Gathering News]
 http://news.scrumalliance.org/Y081v0bNB005T002ZTS0IH0


 There is a lot of exciting news to share on upcoming gatherings! From
 submitting your session for the Phoenix Gaterhing to the Call for Chair for
 Prague, this email serves as your guide to all things Global SCRUM
 GATHERING®! Thinking about attending your first Global SCRUM GATHERING®? Here
 are the top 10 reasons to attend!
 http://news.scrumalliance.org/gJ0T1NZ05200TH08S000cvB

 Interested in sponsoring a Global SCRUM GATHERING® to showcase your
 company? Download the sponsorship package
 http://news.scrumalliance.org/K0051ST00ZvK2d8TB00N0H0 or contact Yvonne
 at yde...@scrumalliance.org
 http://news.scrumalliance.org/MN0H050TSv10800eZ0BT0L2 or (905) 281-0555,
 ext. 111.

 [image: Phoenix Gathering]
 http://news.scrumalliance.org/U5fB01H0ZT0S8v020N000MT

 *Global SCRUM GATHERING® Phoenix 2015*
 Early Bird Registration is 25% SOLD OUT
 Early Bird registrations are going fast! Register today to save $200. Join
 us at the Global SCRUM GATHERING® Phoenix 2015
 http://news.scrumalliance.org/U5fB01H0ZT0S8v020N000MT at the Talking
 Stick Resort.
 Submission System is OPEN
 Submissions are now being accepted for the Global SCRUM GATHERING®
 Phoenix 2015 http://news.scrumalliance.org/U5fB01H0ZT0S8v020N000MT!
 Read the Submission Guidelines
 http://news.scrumalliance.org/x0Sv2N00ZNT0g81BTH5 for more details
 on how to submit – and click here
 http://news.scrumalliance.org/B000hS2HN00010vT0TOZB58 to submit your
 session!
  The submission system will *close at 23:59 EST on November 30* at which
 time reviews will begin. Visit the Global SCRUM GATHERING® Phoenix 2015
 http://news.scrumalliance.org/U5fB01H0ZT0S8v020N000MT webpage for more
 information.

 Thank you to our sponsors: Axosoft
 http://news.scrumalliance.org/j5iT002ZS001T0BNH8P0v00, SkyTouch
 Technology http://news.scrumalliance.org/Y081v0jNB005T002ZTS0QH0, and 
 Learning
 Tree http://news.scrumalliance.org/K0051ST00ZvR2k8TB00N0H0.
 --
 [image: Prague Gathering]*Global SCRUM GATHERING® Prague 2015*
 Call for Chair Closes November 15
  Submit today http://news.scrumalliance.org/CTB00l0SZ0vS0N8T2500H01 to
 Chair the Global SCRUM GATHERING® Prague 2015
 http://news.scrumalliance.org/s0Tv0Z00TTNm0S051B2080H. Submissions are
 open http://news.scrumalliance.org/CTB00l0SZ0vS0N8T2500H01 until
 November 15.

 Sponsor today to receive over a year of promotion as we lead up to the Global
 SCRUM GATHERING® Prague 2015
 http://news.scrumalliance.org/s0Tv0Z00TTNm0S051B2080H. We’re all
 excited to see you there!
[image: curved bottom shadow]
 Scrum Alliance, Inc., PO BOX 40097, INDIANAPOLIS, IN, U.S.A. 46240-0097
 Contact Us http://news.scrumalliance.org/U5nB01H0ZT0S8v020N000UT


 This email was sent to aricha...@wikimedia.org. If you no longer wish to
 receive these emails you may update your email preferences
 http://news.scrumalliance.org/dcu/hOGf8NFugttNQxSLRxxFV9XJFcJeuUxa7F9-VBVukW6uuZunYYua6iAXkn3tXK-vfCNHGCykoDEigbXWoQC8VLmF4sLXZ8Y3IdySaFQPx-_eQkNmAUfqX4G4nz2GrkIlUQ57GgZDOt0CztqEW9J0sg==/DSV100o0HTT00v00ZN2B085
 at any time.



 --
 Arthur Richards
 Team Practices Manager
 [[User:Awjrichards]]
 IRC: awjr
 +1-415-839-6885 x6687




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] mingle seats

[Arthur Richards]

Bryan, want to pitch using the Phabricator board at this week's SoS?

On Fri, Nov 7, 2014 at 4:14 PM, Bryan Davis bd...@wikimedia.org wrote:

 Project and initial board [1] are now live and waiting for content.

 [0]:https://phabricator.wikimedia.org/tag/sos/
 [1]: https://phabricator.wikimedia.org/tag/sos/board/

 Bryan

 On Fri, Nov 7, 2014 at 3:33 PM, Arthur Richards aricha...@wikimedia.org
 wrote:
  You guys rock :) When the board's created I am happy to help support
 getting
  the SoS folks to try it out.
 
  On Fri, Nov 7, 2014 at 3:13 PM, Quim Gil q...@wikimedia.org wrote:
 
 
 
  On Fri, Nov 7, 2014 at 8:53 PM, Bryan Davis bd...@wikimedia.org
 wrote:
 
  The matrix view is cute, but once everything is in Phabricator it
  seems like there could just be a project for each team (like
  https://phabricator.wikimedia.org/tag/mediawiki-core-team/) and a
  project for SoS. Tag your issues with your team, the blocking team and
  SoS to put them in all backlogs. Then the SoS board view could have
  columns for the scheduled, in progress, done and blocked
  status.
 
 
  And then imagine that each card would display the projects it is
  associated with. This is Normal priority upstream:
 
  https://secure.phabricator.com/T4863
 
  ___
  teampractices mailing list
  teampractices@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/teampractices
 
 
 
 
  --
  Arthur Richards
  Team Practices Manager
  [[User:Awjrichards]]
  IRC: awjr
  +1-415-839-6885 x6687
 
  ___
  teampractices mailing list
  teampractices@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/teampractices
 



 --
 Bryan Davis  Wikimedia Foundationbd...@wikimedia.org
 [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
 irc: bd808v:415.839.6885 x6855

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




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] mingle seats

[Arthur Richards]

You guys rock :) When the board's created I am happy to help support
getting the SoS folks to try it out.

On Fri, Nov 7, 2014 at 3:13 PM, Quim Gil q...@wikimedia.org wrote:



 On Fri, Nov 7, 2014 at 8:53 PM, Bryan Davis bd...@wikimedia.org wrote:

 The matrix view is cute, but once everything is in Phabricator it
 seems like there could just be a project for each team (like
 https://phabricator.wikimedia.org/tag/mediawiki-core-team/) and a
 project for SoS. Tag your issues with your team, the blocking team and
 SoS to put them in all backlogs. Then the SoS board view could have
 columns for the scheduled, in progress, done and blocked
 status.


 And then imagine that each card would display the projects it is
 associated with. This is Normal priority upstream:

 https://secure.phabricator.com/T4863

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




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] mingle seats

[Arthur Richards]

On Nov 6, 2014 9:49 PM, Matthew Flaschen mflasc...@wikimedia.org wrote:

 On 10/20/2014 02:56 PM, Arthur Richards wrote:

 PS since the scrum of scrums dependency wall is managed in Mingle, I am
 hesitant to kill accounts for any active WMF engineers.


 We should start thinking about how we can implement this in Phabricator
or on-wiki instead.

Yes! Got any thoughts? I'm not sure we can do it in Phabricator without
engineering effort.
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Burndown charts progress in Phabricatotr (was Fwd: [Wikitech-l] Phabricator update)

[Arthur Richards]

aye aye, awesome stuff!

On Wed, Oct 22, 2014 at 4:03 PM, Matthew Flaschen mflasc...@wikimedia.org
wrote:

 On 10/02/2014 01:31 PM, Greg Grossmeier wrote:

 I'm really excited about this, Quim, thanks to Christopher and the WMDE
 team for taking this on!


 Agreed, this should be a great project.  Thanks!

 Matt Flaschen


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




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Meet-up at WMF: Exploratory Testing for Complex Software, Oct 22 2014

[Arthur Richards]

Just a reminder that this is happening this coming Wednesday, and that we
are planning to record/broadcast the event for remote participants.

On Tue, Sep 23, 2014 at 10:31 AM, Arthur Richards aricha...@wikimedia.org
wrote:

 On Wednesday, October 22, 2014 the Quality Assurance Group and Team
 Practices Group hope you will join us for a meet-up at the WMF entitled
 'Exploratory Testing for Complex Software; Lessons from Cloud Foundry' with
 special guest speaker Elisabeth Hendrickson [1]. We will be discussing
 testing in agile iterative software development, and in particular exploratory
 testing https://en.wikipedia.org/wiki/Exploratory_testing [0]. This
 will be a lively and enlightening conversation, aimed at everyone concerned
 about the overall quality of software - even those who do not necessarily
 contribute code.

 *When*: Wednesday, October 22, 2014, 6:00pm - 8:30pm (for WMF folks there
 is a calendar event on the Engineering calendar)

 *Where*:
 Wikimedia Foundation
 6th Floor, collab space
 149 New Montgomery St.
 San Francisco, CA
 (Accessible for remote participation via Hangouts on Air; link TBA)

 *From the meet-up invite
 http://www.meetup.com/wikimedia-tech/events/207856222/*[2]:
 In modern software development organizations, the days are gone when
 separate, independent Quality Assurance departments test software only
 after it is finished. Iterative development and agile methods mean that
 software is constantly being created, tested, released, marketed, and used
 in short, tight cycles. An important testing approach in such an
 environment is called Exploratory Testing, and the Wikimedia Foundation has
 made significant investments to support Exploratory Testing for its
 software development projects.

 Elisabeth Hendrickson is test obsessed. She was an early adopter and
 vocal proponent of all aspects of agile software testing. She has been
 particularly instrumental in encouraging and defining the practice of
 Exploratory Testing. Elisabeth's 2013 book Explore It!: Reduce Risk and
 Increase Confidence with Exploratory Testing is the standard reference on
 the subject.

 Join us in the Wikimedia Foundation collaboration space to hear Elisabeth
 discuss her experience doing software testing for complex projects, with
 particular examples of Exploratory Testing from her current work as
 Director of Quality Engineering for Cloud Foundry.

 This talk is for everyone involved in the overall quality of software, and
 it will be of particular interest to Project Managers, Product Managers,
 and those working with software development projects who do not necessarily
 contribute code directly to the projects.

 [0] https://en.wikipedia.org/wiki/Exploratory_testing

 [1] Elisabeth Hendrickson is a tester, developer, and Agile enabler. She
 wrote her first line of code in 1980, and almost immediately found her
 first bug. In 2010 she won the prestigious Gordon Pask Award from the Agile
 Alliance. She is best known for her Google Tech Talk on Agile Testing as
 well as her wildly popular Test Heuristics Cheatsheet. In 2003, she learned
 how to do Agile for real from Pivotal Labs while working as a tester on one
 of their projects. In 2012 she decided it was time to take up permanent
 residence in the Pivotal offices, where she is the Director of Quality
 Engineering for Cloud Foundry, Pivotal's Open Source Platform as a Service
 (PaaS).

 [2] http://www.meetup.com/wikimedia-tech/events/207856222/

 --
 Arthur Richards
 Team Practices Manager
 [[User:Awjrichards]]
 IRC: awjr
 +1-415-839-6885 x6687




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] Meet-up at WMF: Exploratory Testing for Complex Software, Oct 22 2014

[Arthur Richards]

On Wednesday, October 22, 2014 the Quality Assurance Group and Team
Practices Group hope you will join us for a meet-up at the WMF entitled
'Exploratory Testing for Complex Software; Lessons from Cloud Foundry' with
special guest speaker Elisabeth Hendrickson [1]. We will be discussing
testing in agile iterative software development, and in particular exploratory
testing https://en.wikipedia.org/wiki/Exploratory_testing [0]. This will
be a lively and enlightening conversation, aimed at everyone concerned
about the overall quality of software - even those who do not necessarily
contribute code.

*When*: Wednesday, October 22, 2014, 6:00pm - 8:30pm (for WMF folks there
is a calendar event on the Engineering calendar)

*Where*:
Wikimedia Foundation
6th Floor, collab space
149 New Montgomery St.
San Francisco, CA
(Accessible for remote participation via Hangouts on Air; link TBA)

*From the meet-up invite
http://www.meetup.com/wikimedia-tech/events/207856222/*[2]:
In modern software development organizations, the days are gone when
separate, independent Quality Assurance departments test software only
after it is finished. Iterative development and agile methods mean that
software is constantly being created, tested, released, marketed, and used
in short, tight cycles. An important testing approach in such an
environment is called Exploratory Testing, and the Wikimedia Foundation has
made significant investments to support Exploratory Testing for its
software development projects.

Elisabeth Hendrickson is test obsessed. She was an early adopter and
vocal proponent of all aspects of agile software testing. She has been
particularly instrumental in encouraging and defining the practice of
Exploratory Testing. Elisabeth's 2013 book Explore It!: Reduce Risk and
Increase Confidence with Exploratory Testing is the standard reference on
the subject.

Join us in the Wikimedia Foundation collaboration space to hear Elisabeth
discuss her experience doing software testing for complex projects, with
particular examples of Exploratory Testing from her current work as
Director of Quality Engineering for Cloud Foundry.

This talk is for everyone involved in the overall quality of software, and
it will be of particular interest to Project Managers, Product Managers,
and those working with software development projects who do not necessarily
contribute code directly to the projects.

[0] https://en.wikipedia.org/wiki/Exploratory_testing

[1] Elisabeth Hendrickson is a tester, developer, and Agile enabler. She
wrote her first line of code in 1980, and almost immediately found her
first bug. In 2010 she won the prestigious Gordon Pask Award from the Agile
Alliance. She is best known for her Google Tech Talk on Agile Testing as
well as her wildly popular Test Heuristics Cheatsheet. In 2003, she learned
how to do Agile for real from Pivotal Labs while working as a tester on one
of their projects. In 2012 she decided it was time to take up permanent
residence in the Pivotal offices, where she is the Director of Quality
Engineering for Cloud Foundry, Pivotal's Open Source Platform as a Service
(PaaS).

[2] http://www.meetup.com/wikimedia-tech/events/207856222/

-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] Effective communication tips for operating across timezones

[Arthur Richards]

Great tips for communicating effectively across timezones
http://thenextweb.com/entrepreneur/2014/09/12/effective-communication-tips-operating-business-across-time-zones/.
From my own experiences, much of this rings true. Hat tip to Alolita for
posting this somewhere I noticed the other day ;)


http://thenextweb.com/entrepreneur/2014/09/12/effective-communication-tips-operating-business-across-time-zones/

-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] Spotify's team health check survey

[Arthur Richards]

The folks at Spotify just published a blog post discussing their health
check survey https://labs.spotify.com/2014/09/16/squad-health-check-model/
[1]-
a primary source of inspiration (and content!) for our own
https://www.mediawiki.org/wiki/Team_Practices_Group/Health_check_survey [2].
I thought this was worth sharing since a number of you asked to see more
details about Spotify's survey.

[1] https://labs.spotify.com/2014/09/16/squad-health-check-model/
[2] https://www.mediawiki.org/wiki/Team_Practices_Group/Health_check_survey
-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Team health check survey: your feedback wanted!

[Arthur Richards]

Now that a few weeks have gone by, the Team Practices Group has synthesized
all the feedback so far and made a second draft of the team health check
survey
https://www.mediawiki.org/wiki/Team_Practices_Group/Health_check_survey.

Please take a look and provide any further feedback - we will be taking
feedback on this latest draft til midnight UTC of 5 September, 2014 so we
can finalize the survey focus areas for the first iteration of the survey
to be delivered to an initial batch of WMF engineering teams in the coming
weeks. Pending their approval, we are planning to deliver the survey to
teams currently engaged or soon engaging with the TPG - mobile web, mobile
apps, mediawiki core, and analytics - by the end of this quarter.


On Mon, Aug 11, 2014 at 3:10 PM, Arthur Richards aricha...@wikimedia.org
wrote:

 The Team Practices Group
 https://www.mediawiki.org/wiki/Team_Practices_Group has begun drafting
 a team health check survey
 https://www.mediawiki.org/wiki/Team_Practices_Group/Health_check_survey.
 *Your feedback on the survey overall as well as your help brainstorming
 focus areas for the survey is greatly appreciated.*

 The survey is intended to help WMF engineering teams identify areas where
 they should focus efforts for improvement and to track whether or not teams
 are improving. It will be delivered at least quarterly and collaboratively
 completed by each engineering team through a workshop facilitated by a
 member of the Team Practices Group. Metrics derived from the quarterly
 delivery of the survey will be used to determine the success of the Team
 Practices Group in meeting its annual goal
 https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals#Team_Practices_Group
 .

 More details on mediawiki.org.
 https://www.mediawiki.org/wiki/Team_Practices_Group/Health_check_survey
 Please review, share your thoughts/feedback, and help us brainstorm
 sensible focus areas for the survey - either in response to this thread or
 on the talk page
 https://www.mediawiki.org/wiki/Talk:Team_Practices_Group/Health_check_survey
 .

 --
 Arthur Richards
 Team Practices Manager
 [[User:Awjrichards]]
 IRC: awjr
 +1-415-839-6885 x6687




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] Announcing #wikimedia-teampractices IRC channel

[Arthur Richards]

Join the Team Practices Group
https://www.mediawiki.org/wiki/Team_Practices_Group in
#wikimedia-teampractices on IRC https://en.wikipedia.org/wiki/Irc (
irc.freenode.net) to chat about software development practices, processes,
theories, and philosophy - as they pertain to Wikimedia engineering and
beyond.

-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] Team health check survey: your feedback wanted!

[Arthur Richards]

The Team Practices Group
https://www.mediawiki.org/wiki/Team_Practices_Group has begun drafting a team
health check survey
https://www.mediawiki.org/wiki/Team_Practices_Group/Health_check_survey.
*Your
feedback on the survey overall as well as your help brainstorming focus
areas for the survey is greatly appreciated.*

The survey is intended to help WMF engineering teams identify areas where
they should focus efforts for improvement and to track whether or not teams
are improving. It will be delivered at least quarterly and collaboratively
completed by each engineering team through a workshop facilitated by a
member of the Team Practices Group. Metrics derived from the quarterly
delivery of the survey will be used to determine the success of the Team
Practices Group in meeting its annual goal
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals#Team_Practices_Group
.

More details on mediawiki.org.
https://www.mediawiki.org/wiki/Team_Practices_Group/Health_check_survey
Please review, share your thoughts/feedback, and help us brainstorm
sensible focus areas for the survey - either in response to this thread or
on the talk page
https://www.mediawiki.org/wiki/Talk:Team_Practices_Group/Health_check_survey
.

-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] Fwd: Please welcome Kristen Lans, ScrumMaster

[Arthur Richards]

Hi everyone,

I'm very pleased to welcome Kirsten Lans to the Wikimedia Foundation, as
the first ScrumMaster [1][2] hire into the newly formed Team Practices
Group [3]. Kristen will be taking over ScrumMaster duties for the Mobile
Web and Mobile Apps Engineering teams.

Prior to joining WMF, Kristen worked for six years with the TED
prize-winning Encyclopedia of Life project [4], a free, open resource that
aims to provide access to knowledge about all life on Earth. Kristen helped
to pilot and facilitate the Encyclopedia of Life organization's agile
development and planning processes, and enjoyed working with the project's
global community of contributors. Kristen is thrilled to be continuing to
work towards open knowledge sharing for all at an even larger scale.

Kristen currently lives in Cape Cod, Massachusetts with her husband and
dog, and is planning to relocate to the Bay Area by the end of the year,
and is looking forward to eating her way through the San Francisco's tasty
restaurants and taking advantage of the amazing outdoor activities in the
area.

[1] https://en.wikipedia.org/wiki/ScrumMaster#Scrum_Master
[2]
https://www.mediawiki.org/wiki/Wikimedia_Mobile_engineering/imported/Mobile_team/Mobile_web/Roles_and_responsibilities#Scrummaster
[3]
https://www.mediawiki.org/wiki/Wikimedia_Engineering/Team_Practices_Group
[4] http://eol.org

-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Please welcome Kristen Lans, ScrumMaster

[Arthur Richards]

Of course I forwarded this without correcting a terrible typo, for the
record, Kristen's name is Kristen - NOT Kirsten ;)


On Fri, Jul 25, 2014 at 11:10 AM, Arthur Richards aricha...@wikimedia.org
wrote:

 Hi everyone,

 I'm very pleased to welcome Kirsten Lans to the Wikimedia Foundation, as
 the first ScrumMaster [1][2] hire into the newly formed Team Practices
 Group [3]. Kristen will be taking over ScrumMaster duties for the Mobile
 Web and Mobile Apps Engineering teams.

 Prior to joining WMF, Kristen worked for six years with the TED
 prize-winning Encyclopedia of Life project [4], a free, open resource
 that aims to provide access to knowledge about all life on Earth. Kristen
 helped to pilot and facilitate the Encyclopedia of Life organization's agile
 development and planning processes, and enjoyed working with the project's
 global community of contributors. Kristen is thrilled to be continuing to
 work towards open knowledge sharing for all at an even larger scale.

 Kristen currently lives in Cape Cod, Massachusetts with her husband and
 dog, and is planning to relocate to the Bay Area by the end of the year,
 and is looking forward to eating her way through the San Francisco's tasty
 restaurants and taking advantage of the amazing outdoor activities in the
 area.

 [1] https://en.wikipedia.org/wiki/ScrumMaster#Scrum_Master
 [2]
 https://www.mediawiki.org/wiki/Wikimedia_Mobile_engineering/imported/Mobile_team/Mobile_web/Roles_and_responsibilities#Scrummaster
 [3]
 https://www.mediawiki.org/wiki/Wikimedia_Engineering/Team_Practices_Group
 [4] http://eol.org

 --
 Arthur Richards
 Team Practices Manager
 [[User:Awjrichards]]
 IRC: awjr
 +1-415-839-6885 x6687




-- 
Arthur Richards
Team Practices Manager
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Publishing notes from retrospectives and other Scrum meetings

[Arthur Richards]

The mobile web team almost always publishes retrospective notes on
mediawiki.org.

I give the team the chance to voice concerns about having the notes
published publicly. If the team ever feels like they should not be posted
publicly, or posted with redactions, I honor that.


On Mon, Apr 21, 2014 at 4:53 PM, Steven Walling swall...@wikimedia.orgwrote:

 Hey everyone,

 So I recently led two retrospectives, one for the typography overall we
 recently did on Wikimedia sites and one for my regular team (Growth, in
 Features engineering).

 We decided to publish the typography retrospective notes on mediawiki.org(at
 mediawiki.org/wiki/Typography_refresh/Retrospective). The Growth team
 notes are slightly more sensitive so we published it on the private office
 wiki.

 I'm wondering do others publish their retrospective notes, publicly or
 privately within the organization? I'm not very experienced running these,
 so I'm wondering what your take is.

 --
 Steven Walling,
 Product Manager
 https://wikimediafoundation.org/

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




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Mingle

[Arthur Richards]

The Flow team has migrated from Mingle to Trello. They may be able to
provide some insight - and I am personally generally interested to hear
about what the migration was like and how the team feels about the switch.


On Mon, Mar 24, 2014 at 8:04 AM, Toby Negrin tneg...@wikimedia.org wrote:

 The analytics team has tried really hard to use Mingle as our agile
 planning tool but we've reached the point where the ROI just isn't there
 and we need to re-assess our use of it.

 I'm looking for some feedback from teams that have migrated from Mingle --
 primarily what did you migrate to and are you happy with the decision to
 move.

 Ultimately, we'd like to use whatever the Foundation agrees on but in the
 short term we need to make some choices.

 thanks,

 -Toby

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




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] [Engineering] Feedback requested on proposal for creation of Agile Specialist Group

[Arthur Richards]

.



On Tue, Mar 4, 2014 at 12:15 AM, Keegan Peterzell
kpeterz...@wikimedia.orgwrote:

 On Tue, Mar 4, 2014 at 12:46 AM, Erik Moeller e...@wikimedia.org wrote:

 In any case, the WMF engineering@ list covers the entire
 engineering/product department and has generally been an inclusive
 place where non-technical participation is welcome. We also created
 the teampractices@ list (public  open) as a more focused place for
 these kinds of conversations about, well, team practices, and this
 thread was copied to that list as well.


 Awesome. I did not know about this new list.

   https://lists.wikimedia.org/mailman/listinfo/teampractices 

 Thanks to those involved in creating it :)


 --
 Keegan Peterzell
 Community Liaison, Product
 Wikimedia Foundation

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




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices