Rhizome

The Editing Hole

Tue, 22 May 2012 00:00:00 -0400

I'm stuck in an editing hole, and not only am I not editing the things I need to edit, I'm not getting anything done.

I'm at a point where I have about 25 things on my personal task list, and 16 of them are editing related tasks: edit the article in this file, edit this fiction, edit this documentation, edit these would-be-blog posts, and so forth. It seems like I went on something of a six month writing bender, and while I did a little bit of editing during this period, I have clearly fallen behind.

There are a number of factors:

I've been making a point of putting editing tasks on the todo list because I want to make sure that I actually finish projects rather than just abandon them. I've not been particularly good with follow through in the past few years, so that's been a big personal improvement project.

The sad part is that my editing queue is probably 10-20 times larger, but I've got some projects on the less-actionable back burner.
I'm not a very good editor.

I'm awful at copy (or otherwise) editing my own work, and while I know that I've become better at this in the past few years. I still know that it's not perfect and so it seems sort of futile, which makes it hard to get inspired to do editing.
I find writing to be rewarding, and given the choice I will probably always choose to write new stuff. While this is clearly a learned response to the kind of work, this doesn't make the effect any less real.
I find editing to be really difficult work.

This is probably related to #2, but editing wears me out. I find it difficult to spend long periods of time editing, which makes it difficult to make any really substantial progress on the pile of editing tasks.

As a result, I take a long time to edit things, I'm most effective at editing in short bursts. I often want to break up longer editing tasks with other kinds of work just to keep a clean mind set. After a week or so of this, I have almost everything else done on the list, leaving me with a big pile of editing that looks even bigger for the lack of other things on the list.

So now, I'm trying the following:

I'm working on making editing tasks smaller, which will turn into more editing tasks, but it'll be possible to face editing tasks in units less than 10 or 20 pages.
Make more tasks for other projects.

There are two ways to get stuff done: 1) You can be really focused and work on one project at a time until it's finished, or 2) you can be working on a lot of projects in parallel and when you start to loose focus, you switch to another kind of project. The idea is that you end up getting more done because you're being productive more of the time. I subscribe to the second theory.

Here's hoping it works!

Onward and Upward!

Git Feature Requests

Thu, 17 May 2012 00:00:00 -0400

The ability to mark a branch "diverged," to prevent (or warn) on attempted merges from master (for example) into a maintenance branch.
The ability to create and track dedicated topic branches, and complementary tooling to encourage rebasing commits in these sorts of branches. We might call them "patch sets" or "sets" rather than "branches." Also, it might be useful to think about using/displaying these commits, when published, in a different way.
Represent merge commits as hyperlinks to the user, when possible. I think GitHub's "network graph" and similar visualizations are great for showing how commits and branches interact and relate to each other.

This would probably require some additional or modifies output from "git log".
Named stashes.
Branched stashes (perhaps this is closer to what I'm thinking about for the request regarding topic branches.)
The ability to checkout "working copies," of different points/branches currently from a single repository at the same time, using "native" git utilities.

Related, "shelf" functionality is scriptable, but this too needs to be easier and more well supported.

I think legit is a step in the right direction, but it's weird and probably makes it more difficult to understand what's happening with git conceptually as opposed to the above features which would provide more appropriate conceptual metaphors for the work that would-be-git-users need.

The Limitiations of the GitHub Fork Model

Thu, 10 May 2012 00:00:00 -0400

Assumption:

git is pretty awesome, but it's conceptually complex. As a result using git demands a preexisting familiarity with git itself or some sort of wrapper to minimize the conceptual overhead.
The collaboration methods (i.e. hosting) provided by git, which are simple by design to allow maximum flexibility, do not provide enough structure to be practically useful. As a result providers like GitHub (and BitBucket and gitorious) offer a valuable service that makes it easier--or even possible--for people to use git.

Caveats:

there are problems with using centralized repository services controlled by third parties, particularly for open source/free software projects.

There are ways that GitHub succeeds an fails in this regard. but this dynamic is too complex to fully investigate within the scope of this post.
If you use GitHub as designed, and the way that most projects use GitHub, then you have a very specific and particular view of how Git works.

While this isn't a bad thing, it's less easy to use git in some more distributed workflows as a result. This isn't GitHub's fault so much as it is an artifact of people not really knowing how git itself works.

Assertion:

GitHub's "fork" model disincentives people from working in "topic" branches.
By making it really easy for people to publish their branches, GitHub disincentives the most productive use of the "git rebase" command that leads to clean and clear histories.
There's no distinction between a "soft fork" where you create a fork for the purpose of submitting a patch (i.e. a "pull request") and a "hard fork," where you actually want to break the relationship with the original project.

This is mostly meaningful in context of the other features that GitHub provides, notably the "Network" chart, and the issue tracker. In a soft-fork that I would intend to merge back in, I'd like the issues to "come with," the repository, or at least connect in some way to the "parent." For hard forks, it might make sense to leave the old issues behind. The same with the network chart, which is incredibly powerful, but it's not great at guessing how your repository relates to the rest of its "social network."

The solution: keep innovating, keep fighting lock-in, and don't let GitHub dictate how you work.

Making Things Easier

Tue, 08 May 2012 00:00:00 -0400

I spent a lot of time in the past few months thinking about "automation," as a project to take things that take a long time and require a lot of human intervention into things that just do themselves, and I think this is the wrong approach.

While total automation is an admirable, it's difficult, both because it requires more complex software to deal with edge cases, but also because it's hard to iterate into a fully automated solution.

Let's back up for a moment and talk about automation in general.

Computers are great at automating things. When you figure out how exactly to accomplish something digitally (i.e. polling an information source for an update, transforming data, testing a system or tool,) writing a program to perform this function is a great idea: not only does it reduce the workload on actual people (i.e. you.) I think the difference between people who are "good with computers," and people who are "great with computers," is the ability to spot opportunities for these kinds of automations, and potentially implement them..

To my mind the most important reason to automate tasks is to ensure consistency and to make it more likely that tedious tasks get done.

Having said this, rather than develop complete task automations for common functions, the better solution is probably to approach automation on the bottom up: instead of automating a complete process, automate smaller pieces particularly the most repetitive and invariable parts, and then provide a way for people to trigger the (now simplified) task.

The end result, is a system that's more flexible easier to write, and less prone to failure under weird edge cases. Perhaps this is a manifestation of "worse is better" also.

?Thoughts?

Onward and Upward!