I thought that there were plenty of good ideas in this article from the
Asana founders, so sharing here in the event that you might think so, too:
https://blog.asana.com/2015/07/workstyle-communication-internal-memo-from-our-founders/
___
teampractices m
On 5 August 2015 at 14:33, Greg Grossmeier wrote:
>
> From the notes of our Quarterly Review in July:
>
> ---quote---
> ==All infrastructure teams, in future quarterly reviews==
> --> Lila: for all teams: assess how much of your time goes to:
> * supporting others
> * new projects
> * prototyping
I would guess that it is also related to
https://www.mediawiki.org/wiki/Developers/Maintainers
and https://www.mediawiki.org/wiki/Upstream_projects
and who (if anyone) is tasked with fixing bugs in extensions/code that no
existing team/individual is currently (officially) working on.
On Wed, Aug 5
> I'm not certain I understand the need to draw a distinction between
> maintenance and new work. I prefer to think purely in terms of what work is
> the most strategic in terms of achieving our mission; for the purposes of
> that, whether work is "maintenance work" or "new work" is irrelevant, as
On Wed, Aug 5, 2015 at 12:31 PM, Joel Aufrecht wrote:
> I'm working on a definition of "interrupt" work that we could standardize
> and measure across the Foundation. The purpose is to inform planning; in
> particular, we probably have a lot of teams thinking they can, or being
> asked to, comple
So I would say the buckets are about rat but I would certainly welcome some
feedback on how we make definitions that are good for engineering..
If I use my house analogy..
Bucket 1 is CORE - It is paying the mortgage, the property tax and copying
with HOA rules and local ordinance and building co
On 5 August 2015 at 12:10, Greg Grossmeier wrote:
>
> Are there any teams at WMF who already have these two buckets defined?
> What are your definitions?
>
Things like restarting the ElasticSearch cluster, and upgrading the
ElasticSearch cluster, are maintenance work for my team. I guess the
crit
Distinguishing between "maintenance" and "new" work seems very gray to me.
Roughly as gray as "bug" vs. "improvement".
I guess a working definition for us right now might be: Either it's part of
a project in the MPL, or it is "maintenance", or there's a reasonable
chance you shouldn't be doing it.
I think I understood Terry's buckets to be:
1. Keep the lights on and servers running, assuming nothing external
impacts them.
2. Respond to external events, such as security patches and library
upgrades.
3. Innovation.
I believe DStrine recently created an "Unplanned" tag in phab
On Wed, 2015-08-05 at 08:16 -0700, Greg Grossmeier wrote:
> e="13:43:12 +0200">
> > I would suggest doing a post-release day (branch cuts happen on Tuesday, so
> > maybe use Wed or Thu) so that if we merge a lot of patches we'll have as
> > much time as possible until the next release cut to test s
On Tue, 2015-08-04 at 16:58 -0700, Arthur Richards wrote:
> Couple of questions - are there plans to document/track
> 'unmaintained' repositories?
That sounds pretty related to the discussion in
https://phabricator.wikimedia.org/T102920 (input welcome!). AFAIK we
don't even have a general "consen
Generally: Thanks for all the feedback in this thread. Appreciated!
On Tue, 2015-08-04 at 14:50 -0400, Kristen Lans wrote:
> Overall seems fine to me, especially given that this is an
> experiment. As with all experiments, I wonder: how will you know you
> are successful? I see things like "All
Following on to Joel's message about "interrupt" work, I'd like to start
a thread on maintenance vs new work.
Context: In the last round of quarterly reviews it was requested that
teams be prepared to give an idea of the proportion of work that falls
into "maintenance" vs "new work".
Now, the har
I'm working on a definition of "interrupt" work that we could standardize
and measure across the Foundation. The purpose is to inform planning; in
particular, we probably have a lot of teams thinking they can, or being
asked to, complete a certain amount of new work, without fully taking into
acco
> I would suggest doing a post-release day (branch cuts happen on Tuesday, so
> maybe use Wed or Thu) so that if we merge a lot of patches we'll have as
> much time as possible until the next release cut to test stuff on the beta
> cluster.
That's a great point, Joaquin, and I agree. If we see a
On Tue, 2015-08-04 at 16:11 -0700, Joel Aufrecht wrote:
> Because VE has around 5000 open tasks and only 800 estimated tasks
https://phabricator.wikimedia.org/maniphest/query/nvSn_H7WxUyO/#R and
https://phabricator.wikimedia.org/maniphest/report/project/
both state that there are 1328 open tasks
I would suggest doing a post-release day (branch cuts happen on Tuesday, so
maybe use Wed or Thu) so that if we merge a lot of patches we'll have as
much time as possible until the next release cut to test stuff on the beta
cluster.
This is a great idea, and we need to think of continuous efforts
17 matches
Mail list logo
