Tom Scheinfeldt

Collaboration and Emergent Knowledge at Greenhouse Studios

Since the 1970s, scholars in fields as varied as sedimentology, ornithology, sociology, and philosophy have come to understand the importance of self-organizing systems, of how higher-order complexity can “emerge” from independent lower-order elements. Emergence describes how millions of tiny mud cracks at the bottom of a dry lake bed form large scale geometries when viewed at a distance, or how water molecules, each responding simply to a change in temperature, come to form the complex crystalline patterns of a snowflake. Emergence describes how hundreds of birds, each following its own, relatively simple rules of behavior, self-organize into a flock that displays its own complex behaviors, behaviors that none of the individual birds themselves would display. In the words of writer Steven Johnson, emergence describes how those birds, without a master plan or executive leadership, go from being a “they” to being an “it.” In other words, emergence describes a becoming.

We, too, form emergent systems. Emergence describes how a crowd of pedestrians self-organizes to form complex traffic flows on a busy sidewalk. Viewed close-up, each pedestrian is just trying to get to his or her destination without getting trampled, reacting to what’s in front of him or her according to a set of relatively simple behavioral rules—one foot in front of the other. Viewed from above, however, we see a structured flow, a river of humanity. Acting without direction, the crowd spontaneously orders itself into a complex system for maximizing pedestrian traffic. The mass of individual actors has, without someone in charge, gone from being an uncoordinated “they” to an organized “it.”

Emergent approaches to scholarly communication have long been an interest of mine, although I’ve only recently come to think of them this way. My first experiment in the emergent possibilities of radical collaboration took the form of THATCamp—The Humanities and Technology Camp—an “unconference” that colleagues at the Roy Rosenzweig Center for History and New Media and I launched in 2008. Instead of a pre-arranged, centrally-planned conference program, THATCampers set their own agendas on the first morning of the event, organizing around the topics that happen to be of most interest to most campers on that day. Another example is Hacking the Academy, a collaboration with Dan Cohen, which posed an open call for submissions to the community of digital humanists on a seven-day deadline. From the patterns that emerged from the more than 300 submissions we received—everything from tweets to blog post to fully formed essays—we assembled and published an edited volume with University of Michigan Press. A final experiment with this emergent approach was a project called One Week | One Tool. This Institute for Advanced Topics in Digital Humanities brought together a diverse collections of scholars, students, programmers, designers, librarians, and administrators to conceive, build, and launch an entirely new software tool for humanities scholarship. Participants arrived without an idea of what they would build, only the knowledge that the assembled team would possess the necessary range of talent for the undertaking. They began by brainstorming ideas for a digital project and proceeded to establish project roles, iteratively design a feature set, implement their design, and finally launch their product on day seven.

The Greenhouse Studios design process similarly provides a space for emergent knowledge making. Greenhouse Studios is interested in what new knowledge might emerge when we allow academic communities to self-organize. We are asking what kinds of higher-order complexities arise when teams of humanists, artists, librarians, faculty, students, and staff are given permission to set and follow their own simple rules of collaboration. This mode of work stands in strong rebuke to what I would call the “additive” model of collaboration that draws resources and people together to serve faculty member-driven projects. Instead, Greenhouse Studios provides its teams with the conditions for collaboration—diversity and depth of thought and experience, time apart, creative tools and spaces—and lets them set their own projects and own roles. At Greenhouse Studios, we’re running an experiment in radical collaboration, exploring what happens when you remove the labor hierarchies and predetermined workplans that normally structure collaborative scholarly projects, and instead embrace the emergent qualities of collaboration itself.

Briefly Noted for August 21, 2018

Test everything; retain what is good.

1 Thessalonians, Chapter 5

Briefly Noted for August 10, 2018

Hugh Trevor Roper on specialization in history…

Today most professional historians ‘specialise’. They choose a period, sometimes a very brief period, and within that period they strive, in desperate competition with ever-expanding evidence, to know all the facts. Thus armed, they can comfortably shoot down any amateurs who blunder… into their heavily fortified field… Theirs is a static world. They have a self-contained economy, a Maginot Line and large reserves… but they have no philosophy. For historical philosophy is incompatible with such narrow frontiers. It must apply to humanity in any period. To test it, a historian must dare to travel abroad, even in hostile country; to express it he must be ready to write essays on subjects on which he may be ill-equipped to write books.

Hugh Trevor-Roper, quoted in Norman Davies, Vanished Kingdoms: The Rise and Fall of States and Nations

In their own words: How tech leaders can help you argue for the humanities

I firmly believe the case for the humanities is best made on its own terms. Rather than bending pretzel-like to explain how the humanities contribute to the prevailing values of techo-industrial capitalism, we should argue first and foremost for the humanities as good in their own right. We should be strong in our conviction that the social and moral goods produced by the humanities are of equal value to the economic goods produced by science, technology, and business. That said, it is sometimes pragmatic to show that even when measured by the standards of science, technology, and business, the humanities are extremely valuable. When arguing our case to decision makers who are themselves members of the STEM fields (e.g. your Dean or Provost) or who have become convinced of the central importance of STEM in the 21st century economy (e.g. legislators or members of your board of visitors), it is often more persuasive to do so on their preferred turf.

One way to do this is to argue from primary data that show the direct economic benefits of arts and humanities in our communities. The American Academy’s Humanities Indicators project is a good place to look for this kind of evidence. Another way is to refer decision makers to the frequent statements of prominent members of the tech community who have spoken out in support of the humanities education and humanities skills as useful in the tech economy. Good examples of this kind of secondary evidence are Mark Cuban’s recent statements warning students off finance and computing in favor of liberal arts; David Kalt’s assertion that “individuals with liberal arts degrees are by far the sharpest, best-performing software developers and technology leaders”; and the example of Slack co-founder Stewart Butterfield’s crediting of his philosophy degree for his success. I’m sure you’ve seen more examples of this type, which I’d love to collect in the comments section below.

Quoting STEM and business types back to themselves is sometimes the most effective way to argue our worth. It’s one thing to say your work is important, it’s another to show that the people your audience respects most say your work is important. It may not be the case we want to make, but sometimes it’s the case we have to make.

The Pseudoiterative Academic

With the semester having just ended, many of us are settling into new summertime routines and hoping those routines supports both some research productivity and some measure of relaxation. For me, in addition to the transition from semester to summer, I’m also transitioning into a more active period for our Greenhouse Studios initiative: our first projects are entering their intensive build sprints, we’re hiring our first full-time staff, and we’re preparing to move into a new, custom-built space on the first floor of the library.

Times of transition are times when we establish new habits—good ones or bad ones—and I’m trying to keep this passage from Kim Stanley Robinson’s 2312 in mind as I transition to summer and Greenhouse Studios embarks on a new phase in its development:

Habits begin to form at the very first repetition. After that there is a tropism toward repetition, for the patterns involved are defenses, bulwarks against time and despair. Wahram was very aware of this, having lived the process many times; so he paid attention to what he did when he traveled, on the lookout for those first repetitions that would create the pattern of that particular moment in his life. So often the first time one did things they were contingent, accidental, and not necessarily good things on which to base a set of habits. There was some searching to be done, in other words, some testing of different possibilities. That was the interregnum, in fact, the naked moment before the next exfoliation of habits, the time when one wandered doing things randomly. The time without skin, the raw data, the being-in-the-world. They came a bit too often for his taste. Most of the terraria offering passenger transport around the solar system were extremely fast, but even so, trips often took weeks. This was simply too much time to be banging around aimlessly; doing that one could easily slide into a funk or some other kind of mental hibernation. In the settlements around Saturn this sort of thing had sometimes been developed into entire sciences and art forms. But any such hebephrenia was dangerous for Wahram, as he had found out long before by painful experience. Too often in his past, meaninglessness had gnawed at the edges of things. He needed order, and a project; he needed habits. In the nakedness of the moments of exfoliation, the intensity of experience had in it a touch of terror— terror that no new eaning would blossom to replace the old ones now lost. Of course there was no such thing as a true repetition of anything; ever since the pre-Socratics that had been clear, Heraclitus and his un-twice-steppable river and so on. So habits were not truly iterative, but pseudoiterative. The pattern of the day might be the same, in other words, but the individual events fulfilling the pattern were always a little bit different. Thus there was both pattern and surprise, and this was Wahram’s desired state: to live in a pseudoiterative. But then also to live in a good pseudoiterative, an interesting one, the pattern constructed as a little work of art. No matter the brevity of a trip, the dullness of the terrarium or the people in it, it was important to invent a pattern and a project and pursue it with all his will and imagination. It came to this: shipboard life was still life. All days had to be seized.

Carpe diem.

When UConn broke up with Adobe: A parable of artists and copyright

One of the things I try very hard to do in my DMD 2010 “History of Digital Culture” class is to teach students that their technology choices are not inevitable nor even determined primarily by what’s “best,” but rather that their technology choices are values choices, reflections of their ethical commitments and those of the communities that create and use those technologies.

When the University of Connecticut’s UITS (University Information Technology Services) made a choice not to renew it’s Adobe Creative Cloud site license, my students correctly judged that this was a values choice about the relative importance the higher administration places on artistic work at the university. The decision not to support software for artists, while at the same time maintaining support for software for, say, engineers, is a statement about how the university values different kinds of work on campus. I was pleased that the students immediately saw that this wasn’t just a choice about the quality of the software or even its cost, but about the intellectual commitments and identity of the university. What the students didn’t so easily grasp, however, was that the controversy over the Adobe suite also reflects on the values choices of the students, on the values choices that digital artists have made over many years to put the Adobe suite and other expensive, proprietary, closed-source software packages at the center of their creative practice, which in turn stems from set of larger choices artists have made vis à vis our prevailing copyright regime.

Artists have largely chosen think about copyright a something that exists to protect them and their work, and they have generally supported our ever-stricter copyright regime. Moving from a humanities and social sciences faculty to a fine arts faculty when I came to UConn from George Mason in 2013, I was struck by how poorly my storm-the-barricades, anti-copyright, open access agenda went over with my colleagues. Not that anyone really cared, but it was apparent from the beginning that I was coming at conversations that touched upon intellectual property (for example, a conversation about making faculty syllabi freely available on the web) from one side of the fence and they were coming at them from the other. Indeed, UConn’s School of Fine Arts offers a course on copyright for artists called Protecting the Creative Spirit: The Law and the Arts, which is taught by two lawyers. You can tell from the title of the course where its sympathies lie.

My DMD 2010 students (most of whom are freshman and sophomores studying in the department of Digital Media & Design which resides within the School of Fine Arts) are no exception. When I teach the unit on copyright, the first question I ask the class is, “What is the purpose of copyright.” Inevitably, students answer with some version of “to keep people from ripping you off.” My next move is to put the copyright clause of the Constitution up on the overhead and explain to them that, in fact, the purpose of copyright is to “Promote the Progress of Science and useful Arts” and that protecting an author’s exclusive rights for a limited term is simply a means to an end.

What is more, I tell them that the ever-stricter copyright regime we live with today wasn’t really designed to protect artists artists at all, although some may have used and benefited its protections. Instead, it was designed by and for big corporations, and it does a much better job of protecting those corporations than it does of protecting individual artists. It is true that many of these corporations employ artists (several former DMD 2010 students are now working for Disney), but those artists’ works are works for hire. The works may be protected by copyright law, but they are protected to the benefit of the employer, not the employee.

It is telling that the feelings of outrage and abandonment regarding the UITS Adobe announcement weren’t evenly distributed among my students. Digital Media & Design students at UConn choose from six different “concentrations,” electing to focus on either 2D animation/motion graphics; 3D animation; game design and development; web design and development; digital media business strategies; or digital culture, learning, and advocacy. (Students from all concentrations are required to take DMD 2010.) Especially hard hit by the news were the 2D/motion graphics students, for whom Adobe After Effects sits at the heart of their practice and for which there really isn’t a substitute, commercial or open source. Letting the Adobe license lapse was basically going to kill their creative practice, or, at the very least, put them out several hundred dollars.

My web design and development students, on the other hand, felt sympathy for their colleagues, but were pretty blasé about the whole thing. For them, letting the Adobe license lapse wouldn’t really change anything. The Adobe corporation has very little leverage over a web developer. To drive the point home, I challenged these web development students to think of a single piece of software that, if taken away from them, would affect their practice in any significant way. A few came up with TCP/IP, but quickly corrected themselves: TCP/IP is a protocol not a piece of software and is an open standard in any case. Apache was another, but, again, it’s open source, and there are serviceable alternatives. Certainly, they couldn’t name a corporation that exists that could raise its prices and bring their web development work to a halt in the way that Adobe was threatening to stop the work of our motion graphics artists. The difference, of course, is that our web developers rely on an open source technology stack and our motion graphics artists rely on proprietary software protected by a copyright law that was written in part by the very companies that produce it. Our web developers are not captive to copyright. Our motion graphics artists are.

Far from protecting artists, this is the best example I have of how our overly restrictive copyright regime harms artists. Rather than teaching our students how to situate their creative practice within a framework of intellectual property protection and thereby reinforce a copyright regime that wasn’t put in place for them in the first place, we should be encouraging our students to resist this regime. We should be teaching them to advocate for open access and open source software. In the longer term, we should be helping them to develop open source and open access alternatives themselves. This is an especially important message for my digital media and design students who, with their considerable skills, will be in a position to effect the longer term project of building the open source tools that will be necessary to free artists’ creative practice from propriety software. In the long term, maybe the very long term, this is the only way we can keep digital artists from being held hostage to corporations as Adobe held my students hostage this semester.

Fortunately, we’ve sorted out the Adobe license issue for now by cutting a licensing deal (shall we call it a hostage negotiation?) apart from UITS for students enrolled in the School of Fine Arts. For now, our students are safe. But only for now. You can bet I’ll be screaming this example over the fence at my colleagues in the School of Fine Arts the next time we talk about copyright.

My new outfit: Greenhouse Studios | Scholarly Communications Design at the University of Connecticut

Looking down the page, it seems I haven’t posted here on the ol’ blog in nearly three years. Not coincidentally, that’s about when I started work on the initiative I’m pleased to announce today. It was in the fall of 2014 that I first engaged in conversations with my UConn colleagues (especially Clarissa Ceglio, Greg Colati, and Sara Sikes, but lots of other brilliant folks as well) and program officers at the Andrew W. Mellon Foundation about the notion of a “scholarly communications design studio” that would bring humanist scholars into full, equal, and meaningful collaboration with artists, technologists, and librarians. Drawing on past experiences at RRCHNM, especially One Week | One Tool, this new style digital humanities center would put collaboration at the center of its work by moving collaboration upstream in the research and publication workflow. It would bring designers, developers, archivists, editors, students, and others together with humanist faculty members and at the very outset of a project, not simply to implement a work but to imagine it. In doing so, it would challenge and level persistent hierarchies in academic labor, challenge notions of authorship, decenter the faculty member as the source of intellectual work, and bring a divergence of thought and action to the design of scholarly communication.

A planning grant from Mellon in 2015 allowed us to explore these ideas in greater depth. We explored models of collaboration and project design in fields as disparate as industrial design, engineering, theater, and (of course) libraries and digital humanities. We solicited “mental models” of good project design from diverse categories of academic labor including students, faculty members, archivists, artists, designers, developers, and editors. We visited colleagues around the country both inside and outside the university to learn what made for successful and not-so-successful collaboration.

The result of this work was a second proposal to Mellon and, ultimately, the launch this week of Greenhouse Studios | Scholarly Communications Design at the University of Connecticut. Starting this year with our first cohort of projects, we will be pioneering a new, inquiry-driven, collaboration-first model of scholarly production that puts team members and questions at the center of research and publication rather than the interests of a particular faculty member or other individual. Teams will be brought together to develop answers to prompts generated and issued internally by Greenhouse Studios. Through a facilitated design process, whole teams will decide the audience, content, and form of Greenhouse Studios projects, not based on any external expectations or demands, but according to their available skills and resources, bounded by the constraints they identify, and in keeping with team member interests and career goals.

Stay tuned to see what these teams produce. In the meantime, after three long years of getting up and running, I plan to be posting more frequently in this space, from my new academic home base, Greenhouse Studios.

Elevator Pitch

Last week I had the pleasure of serving as facilitator at the first Mellon-funded Triangle Scholarly Communication Institute (SCI) in Chapel Hill. For the better part of the week five diverse teams of scholars, librarians, developers, and publishers came together to advance work on projects addressing challenges ranging from data visualization and virtual worlds to providing computational research access to large newspaper collections to building curriculum resources for understanding Sikh religion and culture. It was a great week.

At the end of the event, the teams were each asked to deliver an “elevator pitch” for their project. Quite what this pitch should entail remained something of an open question going into the final day of the Institute, so the project organizers, me included, came up with the following structure, which we shared with the teams the evening before their presentations, on the spot:

“The What” What is your project? What needs does it meet or problems does it solve? How does it meet those needs/solve those problems?
“The So What?” Why does this project matter? What are its implications for the field of scholarly communication? What are its broader impacts for the way scholarship is produced and disseminated?
“The What Next?” What is your plan for implementing your project? What will be the first thing/s you do to advance your project when you leave SCI? How will you maintain working communication between team members in the weeks and months ahead?

It occurs to me that this is a formulation that I have used in many elevator pitches, planning documents, grant proposals, etc. over the years and that it may be useful to others. When you’re trying to convince people to do something, buy something, or support something, these are generally the things they will want to know — What am I buying? Why should I want it? How will you deliver it? Most RFPs, grant guidelines, and the like are variations on this theme. So, when you’re at the early stages of planning a new project, where ever it may end up, this structure may be a useful starting point.

Happy hunting.

What The New Yorker Got Wrong About Lawrence Lessig

In its October 13, 2014 article about Lawrence Lessig’s Mayday PAC, The New Yorker writes:

In 2001, Lessig co-founded Creative Commons, an alternative copyright system that allows people to share their work more freely.

In fact, this isn’t quite right. Creative Commons is not an “alternative copyright system.” It is a licensing regime that uses the existing framework of copyright law to make it easier for copyright holders to release their works under open terms. This is an important distinction in thinking about what Lessig is trying to do with the Mayday PAC, which aims to use the loosening of restrictions on campaign donations that resulted from the Supreme Court’s Citizens United decision to raise millions of dollars specifically in order to elect candidates dedicated to campaign finance reform. The New Yorker titled its piece, “Embrace the Irony,” and the Mayday PAC is indeed an irony. But in the context of Lessig’s earlier work on Creative Commons, it is a familiar one. Both efforts seek to use existing legal frameworks to subvert a status quo those frameworks were intended to support.

Getting into Digital Humanities: A top-ten list

Today I’ll be joining a roundtable discussion hosted by the New York Council for the Humanities for its incoming class of public humanities fellows. I was asked to prepare a “top-ten list” for public humanists looking to get started in digtial humanities, and with the help of friends on Twitter, I came up with the following:

Stop worrying about the definition of DH: One thing people like you, who are starting out in digital humanities do is worry an awful lot about the definition of digital humanities. Is what I’m going really digital humanities? Does it count as digital humanities? I’m here to tell you to stop worrying about whether what you’re doing is or is not digital humanities. Stop worrying about the definition of digital humanities. Digital humanities is not a thing, it’s not a discipline, it’s not a field. Digital humanities is a community of practice and once you enter that community of practice, once you starting working with other people who call themselves digital humanists, who are in that community of practice, once you start attending events where digital humanists frequent, once you start doing those things, once you start entering that community of practice, you are a digital humanist and whatever you’re doing counts.
Enter the circle: The first thing you should do is get yourself on Twitter. I know people are skeptical of Twitter and for some very good reasons. But when it comes to digital humanities that’s really where the community is so I would suggest getting a Twitter account and then getting a couple of other things. Next thing you should do is get a Feedly account. Feedly is an RSS reader. There are other RSS readers that you may want to use. Feedly is a web-based service that’s very easy to get up and running with. Get a Feedly account. Start subscribing to blogs. Start reading those blogs. Start Tweeting the link that you find there. The way that the digital humanities community uses Twitter is to share links to interesting resources, interesting readings, and other things that they find on the web. You start doing that, you’ll start getting followers and you should start following some people. Find a digital humanist you know and whose work that you like on Twitter, find out who that person is following and follow the people that she’s following. Once you start doing that, you’ll start seeing the kinds of issues that digital humanists are interested in. Then what you should start doing is blogging yourself. Go get yourself a WordPress blog. Either host it yourself or host it at wordpress.com. Start writing down your own thoughts, Tweeting links to that. Other people will start putting your feed from your WordPress blog in their Feedly accounts. They’ll start subscribing to your blog, reading your blog, tweeting your links. This is what I call entering the circle. Really, the digital humanities, and I’m going to say this several times during the course of this video, digital humanities is really a community of practice. That’s all it is and so you need to enter that community of practice and the best way to do that, the first way to do that, is online through these social media, that sort of virtuous circle of blogs, Twitter, and RSS feeds.
Start with partners: An interesting thing happened to me when I was preparing this list that I think illustrates the last point on the list and leads us to the next point on the list. When I started writing this up I posted an update to Twitter asking for suggestions from my followers, the community of DHers who I engage with, what they thought were the top 10 lessons that a new digital humanist like yourselves could and should learn. I got a lot of great feedback, some of which is in this talk. I ended up in a long discussion with two colleagues, Jason Heppler and Trevor Owens, and we were debating the merits of whether we should advise people to start with a particular tool if they were looking to get into digital humanities or whether they should start with a research question and find a tool to match that. Should they let the tool determine the research question or should they let the research question determine the tool? And we talked about that back and forth. I tend to lean on the tool side. Other people lean on the research question side. But, in fact, I don’t come down really on either side. I actually think you should start with something else, a third thing, and that’s with collaboration. All digital humanities projects are collaborations or nearly all. There are very few digital humanities projects that you can do fully on your own. Most things require a team of people or at least a couple of people because there’s a lot of different skills involved with digital humanities projects and it’s very rare that one person brings all of those skills to bear, that all of the skills necessary to carry out the project are contained in the skillset of one person. So most projects, almost all projects, are collaborations and what I like to do – and this is my practice, this is the way I work – is I like to find the partners first. I like to find people who I think are doing great work, who I think are interesting, who I think I really want to work with, who are cool, whatever and I look for the spaces between our work, the spaces between the partners where we intersect, where we overlap, where interesting work can be done.
Attend THATCamp: So who are these partners? Well, if you’re a technical person you probably should want to seek out some content folks to provide you with the stuff that’s going to fill the database, that your project is going to be based around. If you are a non-technical person, well, you should probably be searching for some technical assistance, some people with a more technical bent. Those are often the pairings that we find. Where do you find those people? Well, a very good place to find those people if you don’t already know them, and you may. They may be your close collaborators and that’s always the first place to look but if they’re not one place to look for them is THATCamp, The Humanities and Technology Camp. THATCamp started in 2008 at the Center for History and New Media at George Mason University as an unconference, a very informal gathering of people with an interest in the humanities and technology. A very low overhead gathering and a very informal and non-hierarchal gathering where people of all experience levels, all skill levels, all technical interests and backgrounds, all humanities interests and background could get together in a very non-threatening environment to find one another and connect. Since 2008, these events have grown virally and there have now been more than 150 locally organized, grass roots THATCamps around the world. There’s surely one near you. Go to thatcamp.org. You’ll find a map there on the home page, which lists upcoming THATCamps in an area near you. I know there are several going in the Northeast in the next several months and I encourage you strongly to start there as a place to look for partners, educate yourself, and especially to connect.
Write grants, not papers (or write grants and papers): Digital humanities is a projects-based field. What that means is that people and institutions in digital humanities are known more for their projects than for their publications. That means that it’s often more important to write a grant proposal than it is to write a paper. Writing a grant proposal forces you to describe what it is that you’re going to do. Describing what you’re going to do is the first step to getting something done and being done is the goal of every project. So if you want to finish a project, start with a grant proposal. Start with a description of what you’re going to do, not with what you think.
Release Early and Often: When you’re starting a project, sometimes it’s useful to think about the smallest version of that project, the smallest possible version of the project that will still be complete. So let’s say that you were thinking about building a vast archive of digital primary sources. Well what’s the smallest possible version of that project? Well maybe it’s a list of the 10 most important of those sources. Maybe it has some dates, some call numbers, and an image or two pasted to a piece of paper. That is still the project, it’s just not the fully realized, the most elaborate version of the project that you can think of. We sometimes call this the minimum viable product. Then what you do with that minimum viable product is you get it out there as quickly as possible. You get it out there to the audience so that you can receive feedback, bug reports, and then roll that feedback back into the next version of the product, the next minimum viable product, which will have gone some way towards your fully realized version of the project. We call this strategy of minimum viable products and releasing early and often, agile development and it’s how the best digital humanities projects are built.
Digital is always public: One thing this notion of community of practice and release early and often points to is that digital humanities is essentially public humanities. All digital work is public. When you put something out there on the web it is a public document and it will be found by people who you never intended to find it. Means you have to be very careful when doing digital work to think first and foremost about audience. When starting a digital humanities project audience should be uppermost in your mind and as you continue to release versions of the project, to iterate, to work in an agile fashion on the project, always keep in mind the audience for the project.
Try.New.Things: One of the hardest things about digital humanities to me is that the technologies keep changing out from under you. What that means is you always have to be willing to try new things, to try, to fail, to pick up a piece of software, a new method, to work with it, to figure it out on your own. Most digital humanists are self-taught. You can’t wait for someone to train you. The politics of intellectual property aside, one of the reasons that digital humanists love open source technologies and standards like the Web and Firefox and other open source software packages is because you can open them up and you can change the code, and especially because you can break them.
Break something: Breaking things and then fixing them is one of the very best ways to learn a new technology. The ability to break open source software, to figure out what you did wrong, to go in and change it, fix it, and maybe even make it better, is one of the best teaching methods out there.
Lather, rinse, repeat: You will never stop learning. The situation of trying new things, breaking things, fixing them, learning how to do that is something that you’ll have to do continually in digital humanities. The technologies are always changing out from under you. The methods are always changing, evolving. You have to evolve as a practitioner with them.

N.B. As my mother always told me, “do as I say, not as I do.”