A bit of housekeeping I did today:
Tied some of the loose ends together for v0.7.1. If anyone’s interested in working on this over the next few weeks, I’d like to talk about v0.7.2 next week.
Also, some of the code snippets could use love.
Per my earlier post, I’ve gone ahead and moved all of our tasks, bugs reports, etc. to Github. In doing so, I’ve been pretty liberal about deduping feature requests and marking as wontfix. The originals still exist in PT and, for the most part, the closed stories have a tag of either “wontfix” or “moved-to-github”
One neat thing about Github is that you can assign issues to a Milestone. For instance, here are our open issues for v0.7.1. Github also allows us to break features, bugs, etc. down feature by feature. Here are all of our issues for the Calendar. I didn’t realize it before but PT’s UI actually bugged me in this regard.
So, there’s a few outstanding issues I’d like to complete before releasing v0.7.1. This week, I’d like to put together a post about the move to Github (here’s the draft in progress) and another one with links to the press we received for v0.7.
Also, to get everyone’s creativity going, here’s a quick preview to what I’m thinking for v0.8:
What do you guys think about moving project tasks to Github exclusively (instead of PT too)? Might lend to more collaboration if everyone can easily access what we’re working on…
[crickets]
I’m going to start gradually moving things over…
Let’s examine this more closely. Goes GitHub offer the same tagging and workflow options as Pivotal Tracker?
Yes, Github has the ability to create both tags and milestones. The nice thing about creating milestones is that you can more easily work against multiple milestones (e.g. v0.7.1 and v0.8). Github also offers the advantage that other users can create and participate with issues without having to create a new account. I think these advantages outweigh sticking with Pivotal Tracker.
For what it’s worth, I dove in to try and pick up a task or two a week or so back. But I’m not familiar with PT, so it kind of stopped me from doing what I wanted to. I’d be happy using Github.
Yeah, that’s how I feel too. Thanks for the input Ryan.
>
Camayak launched a sexy new website: http://www.camayak.com/
Some of the screenshots place a lot of emphasis on the “flow”, or who is doing what within the system. We don’t expose enough of that imo. Food for thought.
Based on some of the feedback we’ve received thus far, I’d like to make the following priorities for v0.7.1:
Ideally I’d like to release by the end of next week. Takers?
Once we complete these and push v0.7.1, I think we should have a planning chat for v0.8
Also, one more thing: translations. Let’s update the pot file and include a few.
Daniel tagged version 0.7 earlier this afternoon. See the release post here: Edit Flow v0.7: Modular architecture, monthly calendar, and sortable statuses. Congratulations to all involved!
So that we can compare, below is our WP.org Extend stats page as of now:
WP.org EF stats before release
Cool, let’s also include any press mentions in this thread too.
There’s already two things I’d like to get in a v0.7.1 release within the next two weeks:
It’s too bad we didn’t get a mention here: http://kevin.lexblog.com/2012/01/articles/blog-basics/wordpress-likely-to-power-the-future-of-legal-publishing/index.html
Seemed like a reasonable place to mention plugins to make such a workflow for a legal blog possible. I imagine Kevin just doesn’t know about EF.
The two fixes listed above seem reasonable.
Want to leave a comment or shall I?
Glad you asked. Go right ahead
Found another issue: if you used a v0.7-alpha or v0.7-beta and then upgrade to v0.7, it runs the upgrade script again and, because of this, turns some of the modules off because there aren’t any existing values. This shouldn’t affect anyone because they shouldn’t have been using it in a production environment, but noting here because we want to be smarter about this in the future.
The second bullet above now reported in the WP.org forums (with community working together!): http://wordpress.org/support/topic/plugin-edit-flow-07-calendar-issues?replies=3. Apart from fixing the bug, maybe we should show the year?
Yes, we should show the year in the header/title if it’s not the current year.
Fixed both of these
About 30 hours after release:
WP.org EF stats 30 hours after release
Nice bump I wonder what the other spikes are associated with?
Spikes for all plugins are almost always due to releases – you can see pretty much all of our releases (major and minor) connected with those spikes.
Past 20,000!
A bit over a month after releasing Edit Flow v0.7, we're just past 20,000 downloads!
Did some design work on the website this evening: http://editflow.org/
Launch tomorrow midday if I can get the screenshots together and finish the announcement post.
I saw the screenshots I made are getting down-scaled all ugly-like: http://editflow.org/features/calendar/
Want me to redo them to fit (W=660px)?
That’s alright… I’ll take care of resizing. I’m creating other screenshots right now too.
Just had a thought while looking back at @andrewswitherspoon‘s mockups for the calendar: auto-determined editorial metadata. The best example (and my inspiration) is word count.
This would probably be a new “type” of metadata, it would be readonly (uneditable) while viewing a post, and it would be set in code. It likely would only update with page refreshes (so we probably wouldn’t bother offering an AJAX hook to update).
So if you created a term with this new type, you would add code to functions.php that set the value of the term for any given post based on values in the post itself.
We probably wouldn’t ever store this value in postmeta – it would always be calculated. This might be too expensive, though.
Thoughts?
What other points of data do you see fitting into this?
Similarly, column inches (which is based on word count). I’m having a hard time thinking outside of that realm, though. I’m sure other examples do exist–most common word?
This is similar to another idea I have… I’ll have to pitch you sometime
For the v0.7 release later this week, it would be nice if we spruced up our new WP.com website a bit with documentation and examples. In particular, I’m thinking of a few small things:
Can you help out? Let me know what you’d like to take on in the comments, and when you expect to have it done by.
@andrewswitherspoon or @andrewspittle Down for producing nice screengrabs for each feature, and a custom header for the plugin page?
Check out what I just put together for the calendar as an example of what I’m looking for w/r/t feature documentation: http://editflow.org/features/calendar/
I can do the last part — case studies.
Awesome! Think you can have something drafted by the end of the day tomorrow?
Probably. Also on deadline for an event I’m planning, so no guarantees.
Cool, sounds good. If you’d like me to send you some questions so it’s in Q&A format, I’d be happy to.
Edits and additions to the documentation on editflow.org. [Note that the handful of existing links in the text are not included here, but should be retained.]
Home
• Grammar glitch in Edit Metadata screenshot: “What the post needs to be cover”
• Links to http://editflow.wordpress.com/about/ are 404 error
• Modules screenshot links to http://editflow.org/front-page/ which largely duplicates home page
Features
Edit 1st graf:
Edit Flow empowers you to collaborate with your editorial team inside WordPress. We’ve made it modular so you can customize it to your needs. And you can choose which content type(s) each module will apply to.
Add final linked bullet:
• Dashboard Widgets: Stay on top of your site’s content right from the WordPress Dashboard.
Calendar
Edits:
3rd graf:
Not-yet-published posts can be dragged from date to date on the calendar. Click on a post’s title to see an overlay with details about the post, including viewable editorial metadata if you have that module activated.
1st Extend bullet:
ef_view_calendar_cap (filter) – Modify the capability or role required to view the calendar. By default, administrators, editors, authors and contributors can view the calendar.
2nd Extend bullet:
ef_calendar_allow_ajax_to_set_timestamp (filter) – Whether or not dragging an unpublished post to a new date changes the publication timestamp for the post. This is off by default.
Last Extend bullet:
ef_show_scheduled_as_unpublished (filter) – Include scheduled posts when filtering the calendar to display unpublished content. This is off by default.
[Note: In general, it would be helpful to include a detailed example of how to use a filter to change core EditFlow behavior, including specifics on syntax and placement of the filter code (along the lines of http://editflow.org/extend/auto-subscribe-user-groups-for-notifications/). The ideal would be to link each filter bullet to a code block that could be dropped into functions.php (or a secondary plugin) and that would include comments noting the options and syntax pertinent to that filter.]
Custom Statuses
[Note that in the 2nd graf, story budget should be linked to that view, as calendar already is.]
Edits throughout:
Edit Flow’s custom statuses allow you to define the stages of your editorial workflow. Out of the box, WordPress offers only “Draft” and “Pending Review” as post statuses. Edit Flow adds more statuses – like “In Progress”, “Pitch”, or “Waiting for Edit” – which you can keep, change, or delete, as well as add your own custom statuses. You can also drag and drop statuses to set the best order for your workflow. And you can designate any status as the default for new posts – you’re not stuck with “Draft” anymore.
Custom statuses are fully integrated into the rest of Edit Flow and the WordPress admin. On the calendar and story budget, you can filter your view to see only posts of a specific status. Furthermore, email notifications can be sent to selected users or user groups when a post changes status.
Editorial Comments
No edits
Editorial Metadata
Edits throughout:
Keep track of important details about your content with editorial metadata. This feature allows you to create as many date, text, number, etc. fields as you like, and then use them to store information with each post, like contact details, required word count, or the location of an interview. This metadata is not published with the post, but can be viewed in the WordPress admin and displayed on the calendar, story budget and List Posts screens.
You choose which editorial metadata fields will be displayed on these additional screens. Make an item visible to share it with your team for use in the planning process. Or keep it hidden to restrict the information between writer and editor.
Notifications
Edits throughout:
Notifications keep you and your team up to date on changes to important content. Users can be subscribed to notifications for any post, either individually or by selecting user groups. You can quickly search through all your users to find the desired name or email address, or display just those users already subscribed to a post.
When enabled, email notifications are sent when a post is updated or an editorial comment is left by a writer or editor.
(For the extend filters, it would be helpful to note what the default settings are, at least for the first two filters. And the description for the second filter is unclear – what do “former” and “latter” refer to?)
[Minor nit: In the WP admin, the instruction line for Notifications should have user groups as two words, rather than “Select the users and usergroups …”]
Story Budget
Edits throughout:
View all of your upcoming content in a more traditional story budget view, and print out a copy to take to your planning meeting. Posts are grouped by categories (which can be collapsed or expanded), and the view can be filtered by post status, category or author. Customize the date range to show only the content for your next publishing cycle. And set your screen options to display the results in 1, 2 or 3 columns.
If you’re actively using editorial metadata, the data fields you set as viewable will added as columns on your story budget.
User Groups
Rewrite:
For larger organizations with many people involved in the publishing process, user groups help keep your workflow organized and informed. With a single click, you can send an email notification to a selected group of users when a post is updated, or whenever any post is changed to a specified status.
You can keep, change, or delete the default user groups that come with Edit Flow, or create your own set of groups to suit your organization. Edit a group to select those users who should belong to it. Then, select a user group in the Notifications section of a post, and all of the group’s members will be emailed whenever that post is updated or an editorial comment is added.
Dashboard Widgets
New:
These widgets let you stay on top of your content right from the WordPress Dashboard.
• The Post Status widget gives you an at-a-glance summary of all unpublished content on your site, showing how many posts are in each of your custom statuses and linking you to a list for each status.
• Posts I’m Following links you directly to the ten most recent posts for which you are subscribed to receive notifications.
You select which widget(s) to enable through the Edit Flow settings module.
Donate
• PayPal link/icon is broken
Awesome feedback, I’ve updated our documentation with it.
[Note: In general, it would be helpful to include a detailed example of how to use a filter to change core EditFlow behavior, including specifics on syntax and placement of the filter code (along the lines of http://editflow.org/extend/auto-subscribe-user-groups-for-notifications/). The ideal would be to link each filter bullet to a code block that could be dropped into functions.php (or a secondary plugin) and that would include comments noting the options and syntax pertinent to that filter.]
Yes, we’ll get to this eventually…
Andrew Witherspoon are discussing. 
mcstevem, and 
laurenmichell are discussing. 
Crickets