Howdy search team,
Would anyone be interested in collaborating on style guides for Java, PHP,
and any other languages we tend to use amongst ourselves?
It would be super handy to have a reference to reach for when considering
alternative design patterns, plus it would be a lot of fun to think about
how (and why) we might prefer one style over another.
It would also make a convenient way when onboarding new folks (of whom
there will be many) to get them quickly ramped up on how to sling code, WMF
Search Team style.
Also also it would make a convenient way for code reviewers to say "Yo
James, this is totally not Haskell, stop trying to make everything a
monad!".
Thoughts?
For a starting point in Java, perhaps we could use Effective Java[1] as a
template, and (bias alert) sprinkle in some Functional Programming in
Java[2] for good measure.
For PHP, I have no idea what I'm doing, but I have an interesting
Functional Programming in PHP[3] book on my desk that y'all can borrow.
Cheers!
James
1. http://www.amazon.com/Effective-Java-Edition-Joshua-Bloch/dp/0321356683
2. http://shop.oreilly.com/product/0636920021667.do
3. http://www.functionalphp.com/
We are still figuring out all the recurring meetings the team, sub-teams,
and other team subsets should have. But as a first step, can we all agree
that we can drop the Thursday version of our full-team checkin?
Unless someone objects by Wednesday (tomorrow) afternoon, I propose that we
cancel the Thursday meetings, effective immediately (May 14). For now at
least, we can continue to have our full-team checkin every Monday.
Thanks,
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.*
What will be the best way to reach consensus on whether/how to have daily
standups? It's a pretty important topic, and one that seems to have a fair
amount of disagreement so far. Would a meeting be the most efficient way to
discuss options? Or perhaps an IRC chat? Or an email thread (like this)?
I'm open to whatever the group feels most comfortable with. I'm also open
to individuals opting in or out of this discussion, based on your personal
interest level.
Daily standups are a core practice of Scrum, and are generally seen as an
agile best practice. So if we don't have them, it should be a very
conscious decision, and we need to accomplish their objectives in other
ways. The benefits of daily standups that I can think of include:
- Raising blockers (including to the Product Owner and process
facilitator[1])
- Helping developers stay focused on priority work
- Informing the Product Owner of status from day to day
- Team cohesion; daily social connection
There are concerns about having daily standups with remotely distributed
teams in multiple timezones, but other WMF teams have managed to work
around those. Another argument against daily standups is that each sub-team
is too small to get much benefit. However, that discounts the importance of
frequently sharing information with other stakeholders (notably the PO and
process facilitator).
So....how should we proceed?
[1] If we were doing Scrum, this would be the "Scrum Master".
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.*
(Cross-posting in case there are people not on the public list, but on
the private list)
Hey all,
As you probably know, I've been tasked with building a data
visualisation platform that works. I opted to look at third-party
software rather than wrestle with Limn, for maintenance and speed
reasons.
Still a long way to go - mostly on the back end, hooking up connectors
to get the data sucked into Labs from our EventLogging schemas - but
yesterday's work has produced something that looks a bit like
https://upload.wikimedia.org/wikipedia/commons/0/06/Dashboard_example.png
Key takeaways from this:
1. The text, as it says, is in Markdown. If there are problems, it's
incredibly simple to fix. We can list outages and inaccuracies,
explain where the data comes from, all the nice stuff
2. The visualisation is embedded JavaScript and can be resized, zoomed
in- and out-of and highlighted easily.
3. Key statistics are called out in highlighted boxes using common
iconographic elements.
4. It's reactive. IOW, if a new dataset is loaded on the server side
with more up-to-date numbers while you're reading, no problem: the
figures and graphic will, too.
5. The entire thing is 60 lines of code ;)
As the dropdown menu on the left suggests, there will be a lot of
different panels and panes covering data from our different platforms,
and subsets of that data. If you have suggestions for things from the
EventLogging schemas you'd specifically like, let me know and I'll
build them in!
(Moiz: you are absolutely welcome to have at the CSS and colour scheme, too :D)
--
Oliver Keyes
Research Analyst
Wikimedia Foundation
Here is a starting point for discussion about what team meetings we should
have, moving forward. I'm not stuck on any of these specifics. It's just
easier to have a candidate proposal to pick apart, rather than starting a
group discussion completely from scratch. I have probably missed some as
well.
So feel free to question or challenge, or to propose tweaks to or deletions
of, any of these. Or propose more meetings. We might end up with a panel of
meetings completely different from what you are about to read. But here
goes...
1. Full-team checkin (weekly, 25-50 minutes)
This is very similar to the meeting we have been having Mondays and
Thursdays, but with less of a "here is my status" focus, and more of a
"here is what other people might find interesting". The Scrum-of-scrums
stuff probably wouldn't be here, and definitely no looking at workboards.
The primary purposes are team-building and information-spreading.
2. "Sprint" planning (weekly, 25-50 minutes)
Since we won't be using timeboxed sprints, the frequency of this meeting is
pretty arbitrary. The main goal is to make sure the "To do" columns in the
sprint boards never go empty. This is where Dan (and Moiz) would propose
stories to move from the product backlog into the individual sprint boards.
Some combination of tech leads would attend, and would give rough
estimates, raise issues about incomplete specs, suggest alternate
prioritizations, etc. Other developers could be included, but most likely
would be optional (and perhaps very optional). It's not clear to me to what
degree this meeting should (or could) be divided up into segments for each
sub-team.
3. Daily standup (almost-daily, 5-15 minutes)
I think it is useful for the subteams to have some form of meeting more
than twice per week. But to avoid having "too many" meetings, I'll propose
the option of doing these on IRC. I would also propose that each sub-team
schedule its own separate daily standup, but obviously not at overlapping
times. I'm totally open to individual subteams deciding they don't need
daily standups.
These should probably follow standard daily scrum format, unless there is a
reason not to: Each developer (or other information worker) would say what
they completed since the last standup, what they expect to accomplish by
the next one, and if they are blocked by anything. The main benefits of
this are team cohesion, daily focus on what is important, and quickly
identifying blockers.
4. Showcase (biweekly?, 25-50 minutes)
This is a chance for subteams to proudly demonstrate what they have
accomplished. This could be opened up to folks outside S&D, but those
details should be worked out. Especially in the near term, I'm not sure
what frequency would be best. The purpose is twofold: It's always fun to
show what you have done, and it's helpful to other stakeholders to really
see what S&D is up to.
5. Retrospective (biweekly?, 25-50 minutes)
As we settle in, these retrospectives are likely to become shorter, and we
will be able to go deeper on a smaller number of issues, and really discuss
possible solutions. These could be every 3 weeks or monthly, but I would
prefer to have them more often, but shorter. The purpose, of course, is
continual improvement.
6. Technical deep-dives (purely as needed)
I haven't seen a case for holding a standing meeting time open for these,
especially now that the team has 5 different but sometimes-overlapping
subteams.
7. Product backlog grooming (TBD)
Note that this is purely at the product backlog level, not at the sprint
board level. It is not clear to me who would be involved helping Dan keep
the many product backlog items clearly organized.
8. Front-end/back-end coordination (TBD)
I feel like some combination of Moiz/Dan/TechLead would be helpful here,
but don't yet have a clear picture of what it would be.
9. Other
Of course, there would also be various strategy-level and operational
meetings between various combinations of Wes, Moiz, Dan, and Oliver. I'm
especially unclear on what (if any) research/data-related standing
cross-sub-team meetings we should have. And this doesn't count all the
recurring one-on-ones, which are also valuable.
What else did I forget?
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.*
Here is a draft proposal for the process for the Search & Discovery vertical:
https://www.mediawiki.org/wiki/Search_and_Discovery/Process
Thanks to all of you for your patience in getting through this. I know
it has been frustrating at times to not have a process in place. And
not having a shared understanding of the workflow has slowed some
things down. My hope is that this proposal reflects a reasonable
consensus of the team, taking into consideration existing processes,
best practices, and preferences that team members have expressed over
the last week or so.
It is just a draft, so if you disagree with any of it, or have
suggestions for improvement, please either comment on-wiki, or in this
thread. Also, there are some parts that are under-developed, including
the interface between front and back end work, and the role of
testing.
For the "Meetings" section, I chose to postpone finalizing a couple
meetings which seemed to lack consensus. We'll have to figure those
out next week. The other meetings are based on incremental changes
from what we have been doing, rather than a radical overhaul.
Obviously they can be further refined over time, as we see what works
and what doesn't.
Hopefully we can agree to a process early next week.
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.
Hello list,
this is a test mail. If you see it it means you can now also reach
this list as the alias
search(a)wikimedia.org
as requested by Tomasz on https://phabricator.wikimedia.org/T98415
Best regards,
Danie
--
Daniel Zahn <dzahn(a)wikimedia.org>
Operations Engineer
I'm going to be breaking the work boards pretty hardcore this afternoon.
1. I'm going to clean up all the "done" stuff.
2. Everything that isn't done I'm going to add the the sprint boards in the
right columns and then shift to a new "in sprint board" column on the
search team board.
3. Finally I pick some stuff out of the backlog, add it to the backlog in
the sprint boards, and move it to the "in spring board" column.
If that is confusing to you then you aren't alone. I'll reply to myself
when I get a feel for what this ends up looking like.
