Loading Profile...
Recent activity
Subscribe to this feed
Jonathan Grubb replied on March 11, 2010 02:07 to the idea "Make a Get Satisfaction Facebook app" in Get Satisfaction:
I like the Satisfaction Facebook app that brings key features of Satisfaction into Facebook, and this is an idea to make it a bit more specific and possibly more viral.
Facebook is know for its faceless customer service, and has already become an example of Satisfaction's potential to facilitate people-powered customer service. So why not build a "Facebook Customer Service" app in Facebook? Users could get help (and help others) without leaving the facebook fold.
This reply was created from a merged topic originally titled
Make a special version of the Satisfaction Facebook app that just offers customer service for Facebook..-
Jonathan Grubb replied on January 23, 2010 01:04 to the problem "Labels with the ':' character in their names do not work in search." in Pivotal Labs:
If this is still a problem, you can open "View >> Labels & Searches," hit the edit button, and change "Bug: High Priority" to "Bug-High Priority". It will change all instances of that label. -
Jonathan Grubb replied on January 21, 2010 20:30 to the question "What's the best way to split "Accept/Reject" responsibilities among multiple people?" in Pivotal Labs:
Update: we're a week into option 2 and things are working pretty well. It's sometimes hard to make sure that every story has the right person selected in the "requested by" field.
Since I can't find a way to do a boolean search on the requested by field (to find all stories that were are not set to one of the 2 official requesters) I exported all stories to CSV, opened in a spreadsheet, and sorted by requester. Each row has a link that can be dragged into the browser so I can go change the requester manually. -
Jonathan Grubb replied on January 13, 2010 20:51 to the idea "Pin stories to a release/group" in Pivotal Labs:
FWIW, I use labels to group stories into a release, and would prefer not to have the release marker automatically float below the last story. The reason: we often (always?) have stories that we want to apply to a particular release as a hotfix. Example: v4.1 is releasable at some point, but we discover a bug in QA that we want to fix, but that is not a release blocker. We'll go ahead and release 4.1, click finish on the Release story, and keep a 4.1 story active.
I guess this could still work if clicking finish on the floating release story would make it inactive and stay put in the list of finished stories. -
Jonathan Grubb asked a question in Pivotal Labs on January 13, 2010 20:43:
What's the best way to split "Accept/Reject" responsibilities among multiple people?I'm head of product for a software company (doing ongoing internal product development) and up until now I've been the sole customer and done all accepting and rejecting. We're adding a VP of engineering who will take responsibility for the more technical and internally facing stories, while I'll continue to be responsible for customer-facing features and bugs.
I have 2 options in mind to track whom should accept any specific story:
Option 1: Labels
We would apply a label to each story, either "eng" or "prod". We would keep a saved search for those tags, and each person would see the stories ready for them to accept. A big advantage: we can add labels to many stories at once.
Option 2: Change "requested by"
No matter who requests a story, we would use that field to track who is responsible for it. We sometimes refer back to the original requester to get more info on the story, but if the story makes sense to the manager then they can re-assign to their own name before placing it in the backlog. Biggest advantage: stories will show up in the right person's "my work" list and they will get the right emails.
Does anyone have experience with this, or general thoughts on the issue? After writing this up I'm leaning toward option 2.