Re: [teampractices] Keeping track of activity in tasks in phabricator

2016-05-18 Thread Nick Wilson (Quiddity) 
I've recently started to use a Herald rule, to send me a single email (but
not subscribe) when a new task is created (in a project I'm interested in).
This way I can keep track of when people file new tasks.
I can then selectively triage or subscribe to the tasks, as desired.

See setup in this screenshot
http://imagizer.imageshack.com/img924/9136/LaJQAR.png
Especially that last line "Is newly created = true".
Configure your own rules at https://phabricator.wikimedia.org/herald/

(More documentation is at
https://www.mediawiki.org/wiki/Phabricator/Help/Herald_Rules including the
warning "Please do not create herald rules simply to watch a project.
Herald rules take time to execute which means they make phabricator run
slower for everyone.")


On Wed, May 18, 2016 at 9:21 AM, Max Binder  wrote:

> I've tweaked my personal dashboard a bit to help with this, though I think
> that is really just another visual alternative to email and
> Phab-notifications. I echo Kevin, I'm curious how POs handle this (and
> wonder if the POs should be the drivers in grooming meetings, since they
> are touching most tasks anyway).
>
>
I keep meaning to overhaul my (default) dashboard.
If you have any great examples or tips on the modules, please add them to
https://www.mediawiki.org/wiki/Team_Practices_Group/Phabricator_tips/Dashboards
(the main link that is pointed to from
https://www.mediawiki.org/wiki/Phabricator/Help#Using_Dashboards )
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Some recent articles about the benefits and costs of collaboration

2016-05-09 Thread Nick Wilson (Quiddity) 
and a couple more, slack-specific:

https://blog.agilebits.com/2016/04/19/curing-our-slack-addiction/

http://qz.com/632016/why-im-breaking-up-with-slack/


On Mon, May 9, 2016 at 12:41 PM, Grace Gellerman 
wrote:

> A spectrum of opinions on the benefits and costs of modern workplace
> collaboration:
>
>
> https://hbr.org/2016/01/collaborative-overload?utm_campaign=harvardbiz_source=twitter_medium=social
>
>
> http://www.economist.com/news/business/21688872-fashion-making-employees-collaborate-has-gone-too-far-collaboration-curse
>
>
> https://m.signalvnoise.com/is-group-chat-making-you-sweat-744659addf7d#.u8yqelwiy
>
>
___
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

2016-04-29 Thread Nick Wilson (Quiddity) 
On Thu, Apr 28, 2016 at 11:29 PM, Andre Klapper 
wrote:

> Documenting this feature on
> https://www.mediawiki.org/wiki/Phabricator/Project_management#Boards
> is welcome, whoever finds 5 min & feels like understanding it :)
>

{{done}} - Hopefully that's clear; if not please rewrite!
https://www.mediawiki.org/w/index.php?title=Phabricator/Project_management=2110112=2108268#Boards
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] Color schemes (was Re: Hazards of back-estimating backlog story points)

2015-08-04 Thread Nick Wilson (Quiddity) 
(sidenote, re: graph colors. If it's configurable in the software used to
generate those graphs, I'd recommend picking colors via
http://colorbrewer2.org/ in the future. It is designed for generating
easily distinguishable color schemes. Clicking the colourblind safe
checkbox is also recommended (I'm not sure if it was a problem in the
images below. Just always a good practice. :)  HTH.)


On Tue, Aug 4, 2015 at 4:11 PM, Joel Aufrecht jaufre...@wikimedia.org
wrote:

 *tl;dr:* We assigned a default point value to all unestimated tasks in
 the VE backlog, but exploration revealed that this was wrong.  Moral: the
 more assumptions you make about your data, the more ways you need to
 inspect it for the consequences of bad assumptions.

 *Executive summary*
 Lead-time analysis of VE revealed that the VE team puts almost all of its
 effort into very old (2-3 + months) tasks.  By other measures, however, the
 VE team puts a third or more of its effort into interrupts, unplanned
 work.  So either the interrupts are things that sit dormant and then erupt,
 or something's funny in the numbers.  Further investigation revealed that
 the assumption that all unpointed tasks are five points of effort conflicts
 with real-life observation, in which many unpointed tasks are closed every
 week with relatively trivial effort.  Not necessarily because they are
 actually very low effort, but more because they are record-keeping issues
 (duplicate, overtaken by events, fixed as a side effect, etc) than fresh
 work.

 *Details*
 Because VE has around 5000 open tasks and only 800 estimated tasks,
 backlog analysis is impossible without making assumptions about the open
 tasks.  Based on average point sizes for estimated tasks, we assigned a
 value of 5 to all unestimated tasks.  (VE doesn't use 5 in normal task
 estimation, so all 5s are former nulls.)

 I generated this lead-time chart, which shows the age of tasks that get
 resolved every week.  Dark blue means the task is less than a few weeks old
 on the day it gets resolved; light blue means the task is months old.  It's
 scaled by value of tasks, not raw count.


 ​This suggests that the VE team has been spending 80% of effort recently
 closing very old tasks.  This seems like a recent trend, but since almost
 all data was loaded into Phabricator in late January, near the beginning of
 the chart, tasks look artificially young on this scale for the first few
 months. This next chart shows what fraction of VE team effort goes to
 interrupt tasks, as opposed to planned work.  The line is total work
 completed; the black area is interrupt work:

 ​The implication of the two charts together is that the VE team is working
 on a third or more interrupts, but most of those interrupts are months
 old.  Which is an odd thing, since most interrupts are actually a week or
 two old.  So we dug into the task sizes for done tasks by week:


 ​The teal color in this chart is 5 point tasks, i.e., tasks that were null
 points and that we assumed are actually a default of 5.  This chart says
 that half of more of the effort each week has been on null-point tasks.  In
 practice, however, the VE team is confident that this has not actually been
 happening.  What is actually happening is that the VE team closes a number
 of null-point tasks each week because they are duplicates, or incidentally
 fixed by some other task, or otherwise more administrivia than substantive
 primary development.  So the assumption that null-point tasks are really 5
 points of work may hold true for the main backlog, but is not true for
 tasks that actually get marked done.

 So.  First, I identified a list of 470 resolved stories with zero points,
 and the VE team will retroactively assign points to these, the majority of
 which we expect to be 0 or 1 point.  Second, the VE team will have to start
 making sure to assign points to each task as it gets closed.  Third, we
 will have to reconsider our assumptions about how big the unpointed VE
 backlog is.


 *Joel Aufrecht*
 Team Practices Group
 Wikimedia Foundation

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




-- 
Nick Wilson (Quiddity)
Community Liaison, Product
Wikimedia Foundation
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Why are WMF Department/team pages on mediawiki.org?

2015-05-21 Thread Nick Wilson (Quiddity) 
A few thoughts...

Putting anything on wikimediafoundation.org
a) greatly limits the number of people who can edit/update the pages at all
(IIRC not all staff have had accounts created at that wiki. And non-staff
have to request an account via meta
https://meta.wikimedia.org/wiki/Request_for_an_account_on_the_Foundation_wiki
)
b) reduces who will see any updates in their watchlist (I assume I'm not
alone, in not checking my watchlist at that wiki very often. Plus it
becomes very difficult for anyone without an account on that wiki to keep
track of changes)
c) and makes it very difficult for anyone to communicate with the team as a
whole, onwiki. (IIRC many pages at foundationwiki have equivalent pages on
meta, for exactly that reason.)
d) adds a (bad) symbolic separation between staff and the communities.

Wikitech isn't part of the SUL system, so has similar (but smaller)
problems.

I believe the historic reason that the product teams have their team pages
at mediawiki, is because that was (and still is) essentially their home
wiki - where all the primary onwiki documentation and discussion occurs.
Similarly, the depts such as Community Resources
https://meta.wikimedia.org/wiki/Community_Resources have their team page
at meta - their home wiki, where their core work occurs.

Hence, I would recommend meta or mediawiki, as the best place to continue
keeping documentation about individual teams.

The argument could be made that *all* team pages should be on meta, and
that seems reasonable to me at first thought (but it's ~2am so don't hold
me to that!), but I'd suggest asking much more widely before proposing a
move of that magnitude.
However, I'm still not clear on what it would *solve or improve*, and IAR
https://meta.wikimedia.org/wiki/Ignore_all_rules exists to prevent us
from slavishly following rules just for the sake of it. Possibly I'm
missing a perspective or three, though!

Tangentially, I would very much like us to *link to* those existing
meta/mediawiki team pages, more consistently/thoroughly, from the staff page
https://wikimediafoundation.org/wiki/Staff_and_contractors. I've been
meaning to suggest that for a while, and will do so once this discussion
comes to a conclusion.

Hope that all helps!
Quiddity


On Fri, May 22, 2015 at 1:05 AM, James Douglas jdoug...@wikimedia.org
wrote:

  Naively, it seems like our home page should be on
 wikimediafoundation.org rather than mediawiki.org.

 +1

  For engineering departments, it is less clear, but since the entire
 department structure is an artifact of the WMF, and not of the mediawiki
 software, my gut reaction would be the same.

 +1

  Technical pages (such as CirrusSearch) make sense to be on mediawiki.org.


 +1

  Are there historical or cultural reasons to keep the team pages on
 mediawiki.org?

 /me shrugs


 On Thu, May 21, 2015 at 3:23 PM, Alex Monk am...@wikimedia.org wrote:

 Thank you for this email, Kevin. This is something that's bugged me for
 several years as a mediawiki.org administrator - are these pages
 actually within the site scope
 https://www.mediawiki.org/wiki/Project:About#What_MediaWiki.org_is? (I
 don't think I've ever deleted a page for it, but they don't exactly make
 sense as mediawiki.org pages)
 Some of those really Wikimedia-specific technical pages should  probably
 be on wikitech.wikimedia.org, and some of the more WMF-organisation
 (i.e. teams) pages on wikimediafoundation.org, in my opinion.

 On 21 May 2015 at 23:14, Kevin Smith ksm...@wikimedia.org wrote:

 Naively, it seems like our home page should be on
 wikimediafoundation.org rather than mediawiki.org.

 For engineering departments, it is less clear, but since the entire
 department structure is an artifact of the WMF, and not of the mediawiki
 software, my gut reaction would be the same.

 Technical pages (such as CirrusSearch) make sense to be on mediawiki.org.


 Are there historical or cultural reasons to keep the team pages on
 mediawiki.org?


 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




 --
 Alex Monk
 VisualEditor/Editing team
 https://wikimediafoundation.org/wiki/User:Krenair_(WMF)

 ___
 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




-- 
Nick Wilson (Quiddity)
Community Liaison, Product
Wikimedia Foundation
___
teampractices mailing list
teampractices@lists.wikimedia.org
https