So, you’ve taken a liking to Edit Flow and decided you might want to give back. This is awesome — we’d love to have you help. Depending on how much time you have, your skill set, etc., there are a couple of ways you might consider.
We’re always receptive to bug fixes and very considerate of feature requests, especially if you’re willing to do the legwork.
The code for the plugin is hosted on GitHub and use master as our working branch. For small things, feel free to submit a pull request against that. For larger items, we’d love to see the working branch in your fork before attempting a merge. Our task/milestone management is in Github issues. Discussion happens on our development P2.
In addition to improving our existing features, we’re also thinking about these two things:
- How to make the creation and editing process more social.
- How to give writers and editors the data they need to make their content resonate with their audience.
Currently, because this is an open source, “work on it when we have time” type of project, we don’t have a formal release cycle. If we get more developers involved in the project (and this means you!), we will most likely go that route. In the meantime, we recommend becoming familiar with the features and codebase, saying hello, and getting involved in the discussion on our development blog.
Help other Edit Flow users
We point all of our support requests to the WordPress.org forums for Edit Flow. It would be stupendous to have you help out answering questions.
If you’re logged in to WordPress.org, at the bottom of the page you can subscribe to all forum updates with the tag:
This is how we (and you) can respond quickly to new questions, bugs, feature requests, etc.
For questions about how to do something, the best approach is to leverage existing documentation. Summarize the answer, and link to the primary source. If the primary source is missing the requisite information, update it after answering the question. If it’s a completely new question, write a primary source document for it and then link to that. This approach ensures our documentation is always kept up to snuff, and users don’t have to sort through forum threads to try to find their answer
For new bug reports, we assess the message to see if there’s enough information to try to reproduce it. If there isn’t, we’ll ask for screenshots, step by step instructions, and ask them if the problem persists with all plugins disabled except Edit Flow. Once we get detailed instructions, we’ll try to mimic the user’s setup as much as possible in our local environment and test their report. Sometimes when we’re unable to reproduce the issue, it’s a conflict or problem with another plugin. Genuine bugs should be filed as GitHub issues with careful “I did, I saw, I expected” instructions and, preferably, a more detailed diagnosis as well.
For feature requests, our goal is always to under promise and over deliver. Edit Flow’s goal is to enable you and your team to more effectively publish with WordPress. Small features valuable to a certain group of users can sometimes be delivered with just a code snippet — it’s often better to write this and teach them how to incorporate it into their site instead of making it a feature, creating a UI for it, etc. Bigger feature ideas should be posted to our development blog, discussed, scoped, and prioritized. They’ll get built if they have an owner, and probably won’t if they don’t.