What is ChatOps? A guide to its evolution, adoption & significance

HipChat blog runs a rather lengthy post on what ChatOps are – “What is ChatOps? A guide to its evolution, adoption & significance“, which provides some insight into how the new generation of teams communicate.

At Qobo, we are at Stage 3 – Gimini, with a whole lot of dedicated rooms (one for each project, and a few more), some workflows (most notably “Hey Leonid, can you merge and deploy this pull request please“, or a shorter “@leonid, please m&d”), and some automation (we get monitoring notifications from Nagios and Zabbix, repository activities from GitHub and BitBucket, as well as do project deployments using slash commands).

We haven’t eliminated email completely, but combined with Redmine project management tool, we’ve significantly decreased the role of unstructured emails in our work.

Thoughts on Running an Open Source Project

Thoughts on Running an Open Source Project

I love it when people share their code, just make something and publish it, but to my mind it isn’t an open source project until it has people around it. There’s nothing wrong with building something as a hobby, but it’s quite different to have people around it.

On managing Linux kernel development

The Linux kernel is one of the largest collaborative software projects in the history of the world and has almost nothing in the way of formalized management structure. We have people who have a strong operating systems background who have been contributing code, and then we have people like me. I have a background in fruit fly genetics and yet someone lets me get close to the Linux kernel; this seems wrong. And then we have people who are genuinely kids in their bedroom. It’s a miracle it works as well as it does. We should be astonished that we’re able to get it so right so much of the time.

Matthew Garrett

north – design and development standards to align and guide your project

north – design and development standards to align and guide your project

Often referred to as waterfall, the old method of a static page being created by a designer, approved by a product owner, and then handed off to developers without further communication does not produce results in the best interests of anyone involved. The product owner doesn’t see the final product until it is all finished and ready for launch, much too late to make any significant corrections or alter the path of the project.

Instead, a more agile process, where product owners, designers, and developers all work in conjunction with one another to build value in a product throughout its development cycle, is needed. One where a small amount of work and constant feedback between all parties can build a large project out of small parts. One where the final project may not have every bell and whistle hoped for, but rather has an array of features that fulfill the maximum potential of the cost of development based on business and user needs. This is a large change in the way most individuals and organizations have done this type of work in the past, but by sticking to this process, a better product will be built in the long run, and those involved in the building will not be exhausted or burnt out by the process.

The most elegant TODO list

Yesterday I came across a really elegant solution to the TODO list problem.  I tried it out and got immediately hooked!  If you are one of those people who practice variations of Zero Inbox approach – especially with your Desktop icons, I strongly recommend you try it out.

After using it for a few hours, I however patched it up a bit.  Here is mine.  It’s the same approach, just slightly more tilted towards my needs.  More specifically:

  • Use directories instead of empty files.  Empty files are handy for any notes you need to throw into the TODO item, but directories are even more useful, cause I can drop related files into there and then get rid of all of them in one go, once the task is done.
  • Run “todo” without any parameters to get the list of TODO items.