Open Journalism & the Open Web

+1 on Nancy's comment. While I understand the basic concept of scrum and agile project management, I think the nuances and terms are a bit lost on me.

I agree with Nancy. If the overall goal is clear communication between silo-ed departments, maybe we go a little easy on the wordsmiths. Just until we get our feet wet. Some of us - I'm taking the Fifth here - arch our eyebrows at the corruption of "iterate." Which to us, the way it's being used by developers, is a $100 word for "improvement." Be gentle, programmers. We're on board. We're here. We want to learn. But we have a little learning to do.

Functionality in what sense? Who is the product owner? The end-user? Business domain?

David, I'm reading the lack of specificity to mean that it doesn't matter. At least, I'm hoping that's what it means. Let me know p2pu.org, if I'm reading that incorrectly.

I'm a software developer and I knew that the 'jargon' part would be the main stumbling block. I say that as someone from my profession that thinks there's too much of it. For very heavy tech discussions, I can forgive it. But in most other situations (I include tech team updates, as well as *any* team meeting that includes anyone outside the developers team), I insist on plain grammatical language.

One of the starting points is usually some sort of requirements specification document that's being drawn up and updated. It is vital that the requirements specification is written in clear, unambiguous spoken language. At the very most, the "hacks" here *might* need to understand Use Case diagrams - but it's no huge deal if you can't.

Use Case diagrams, incidentally, show "stick men" with a role and a "piece of functionality" drawn from the stick man to the black box system and how that relates to other pieces of functionality.

Do any of the other hackers have any feedback?

I really appreciate this discussion. It is really something that I see a lot. I consider myself a developer right now, but I also am the only one who works with journos on a day-to-day basis so I find myself translating frequently.

This is where the 'specifics' of a project end up getting vague--people are talking 2 different languages. This is why for so many projects real details and requirements don't show up until there is a product in front of the client.

I have found that artwork is extremely helpful for this. Sometimes stick figures help out, but I find that a real designer drawing out a mock of the final document, even if it is very data intensive, can really serve as a way to take a conversation to a place where both hacks and hackers can talk.

Now this is very different from designing in a programmatic sense. In programming designing an application is thinking out the functions, objects and ways to interface with the application. I prefer to do this phase by documenting what the program will do (known as documentation driven design). I also run this documentation by the project managers and other stakeholders and ask for feedback. Even though the documentation is technical, and the stakeholders don't understand all of it, it is helpful and provides them with a looking glass into the application, which they would otherwise have no idea of how it works.

The idea of a 'black box' in programming especially in the design phase frequently comes up. A black box is a section of programming which is what it says, opaque. The programmer knows what the input is and what the output needs to be, but is unsure what exactly needs to happen to go from input to output. Frequently this is a way for a programmer to differ until he actually sits down and creates the functionality. I think it is important to come back to the black boxes in documentation and fill in the details so all involved know how that problem was solved.

I love documentation driven development because it starts high, frequently fo me with a designer's mock up, and gets down into function-by-function, variable-by-variable pseudo code. It makes programming easier, really integrates into Agile development well and communicates with people from both sides of the divide.

Just wanted to go through my preferred process and wish every project I worked on went this way. I hope it wasn't too technical or simple.

And many thanks to David and the other "hackers" here for helping to clarify the assignment. Though I suspect that Rob left the assignment intentionally vague, my sense is that he's referring to just about any "Wouldn't it be nice if..." thought you've had recently about your work in relation to technology. For example, is there something that you'd like your news organization's website to do? Or, from last week's assignment, do you wish that there was an easier way to extract information from stories, or an easier way to manage your sources, or -- for hackers -- some technical challenge that you've dreamed up over the last few course lectures?

Per the comments above, the aim is to think of a conceptually "whole" thing and then to break it down into its component parts, and think about the challenge of prioritizing those, and so on.

Let me know if that's helpful. :)

Phillip.

Regarding the itch I want to scratch, I'd like to automatically compile mailing lists of people who contact me on my Wordpress blogs. I'd also like to find a database I could use to keep track of people I've interviewed, possibly with room to paste in some detailed interview notes. (I suppose that's not a programming question so much as a request for a recommendation. I work alone, so no company database to turn to.)

Also, is there a 'functionality' that will display the most recent comments first on this site?

I will suggest that. But would creating and adding that option (to reorder the comments on this page) be considered a functionality? For my assignment I was thinking it would be nice to make a way to help old people receive and send email. Like making a skin that would come onto the screen when they turn on the computer. It would have 3 big (easy to read, easy to click) buttons on an otherwise blank screen: 1. See new email; 2. Send an email; 3. Look at something on the internet. Depending on which button they clicked it would present an ultra-simple, large-type screen with goof-proof choices that would lead them through the steps to do what they wanted.
But it seems like I could probably use a bunch of macros (assuming they still have macros) to somehow do that. So is what I'm thinking of really a "functionality"? Or is it a collection of functionalities? I understand that there are a lot lot lot of tiny steps that would have to be written in code (coded?) to make this happen if one was starting from scratch. Are there repositories of code modules that kind of click together like electronic components? Is there a technical diagram that is analogous to a schematic that you could use to describe the code components and the flow of (some word for whatever flows through the computer)? Hackers, I would be interested in hearing how a writer could best describe a desired functionality. Is it more helpful to have a really detailed (probably verbose) description of why it's needed, who will be using it--including their savvy level, time constraints, teachability etc.--and how the results will be used?
Or would a flow chart type diagram be easier to work from? Are there questions that come up repeatedly when you are working with the hack side? Are there right-brain, left-brain issues of different approaches to searching or storing information?

Over the weekend I went to the "Opensourceathon" in New York, where a bunch of programmers and journalists divided into teams to code and release some open-source software. Daniel Bachhuber, formerly of CoPress and Publish2 and now with CUNY, came to the meetup with the idea of creating a way to structure comments in WordPress. Dividing comments into different types would enable bloggers to solicit particular kinds of feedback, and it would enable users to view particular types of comments.

I joined this team, along with Jeremy Zilar, Kate Ray, Jeff Marx, Greg Linch and Scott Russ. We were joined later by Albert Sun.

We were pretty good at coming up with what we wanted to do, but after a couple of the people had to leave -- the people who were familiar with WordPress development -- the rest of us struggled to build this.

We didn't actually do the part of the assignment in which we planned how to develop the functionality, which is probably one reason we struggled with putting this together -- we were unfocused in how we tried to solve the problems, and we didn't do a good enough job of establishing priorities and breaking down responsibilities. It was still a productive experience.

By the way, I didn't tell the group about this assignment. This is how Daniel started scoping it out, and later I realized it fit perfectly with the assignment.

The other teams did some great stuff, such as creating a way to back up databases on multiple servers, setting up a way to deliver custom Python settings to different servers, improving upon RadTrack, an agile project management tool, and others.

Below are our working notes from the project. In some places I've expanded on them for clarity.

Functionality
Enable WordPress site to assign content types to comments in order to help an author solicit particular types of feedback or content.

Features
Core
- Define different types of comments (e.g. question vs. correction vs. facts, etc.)
- Allow WordPress users to add comment types in back end
- Post meta box (or addition to the comment post meta box) that enables an author or editor to select the different types of comments they're willing to receive
- Allow users to sort comments by type in order to find the content that they want
- Enable special e-mail notification for comments of "correction" type
- Make some types of comments private

Long-term
- For each user contribution, provide short URL and share buttons for Twitter (oAuth), Facebook (Connect), OpenID
- Access and re-use comments elsewhere in the WP admin (as quotes in future stories, for a round-up post, etc.)
Maybe for future
- Connect comment to related part of the story

Comment Types:
- Questions
- Answers
- Facts
- Replies
- Poems / Haiku
- Contact information (is this visible to anyone on the front end?)
- Text Comments - typical open ended comments
- Text Comments w/ Limit - typical open ended comments with a word limit
- Media Comment - allow URLs to images already posted on the web (Steve: wouldn't this just be a special use of the link sourcing comment?) Greg: We could set it to grab the image if the URL ends with an image extension (jpg, png, gif, etc)
- Correction Comment -
- Link Sourcing Comment - input fields with where readers can provide example links
- User contribution/lead

Development tasks in order of priority:
Core
Study WordPress' "comment-meta" table and fields to see how it can be customized for this purpose
Create basic content types in back end
Create dropdown menu on comment post page to enable users to select type of comment
CSS for comment type descriptor to appear on front end posts
CSS to enable users to select comment types to view

This is a *great* summary, Steve. Many thanks for sharing. :)