I had a really enjoyable conversation with @jphager2 last week. One of the things we discussed was how to improve the visibility of this project, ongoing development in particular. I put a good deal of thought into this over the last few days and have some ideas that I want to share.
Before I do that though I want to explain where we are today. Pakyow emerged to fill a gap in how I believe we should be building for the web. This approach is a big part of how we build things at Metabahn, a company I started over 9 (!) years ago.
Pakyow is something that we as a company continue to support. We want to see the framework continue to improve and become successful. Currently, a portion of my time every week is set aside to work on Pakyow. This is nice because it provides a bit of financial support to the project (something that most open-source projects don't have).
Within the company, Pakyow is treated like any other project. We discuss new features regularly and I provide weekly updates to the team. Some weeks are more productive than others, but there's always a general feeling of movement around the framework. The problem is that most of these discussions happen in private. In hindsight, this is obviously bad for the community.
The obvious lack of visibility is something I want to fix. I see three main problem areas:
- New features aren't publicly discussed, so we miss out on community input.
- Implementation details for new features aren't published, discouraging outside contribution.
- Progress isn't reported (aside from Github activity), so it's hard to know where the project is.
Here are some thoughts on how we can solve these problems:
1. Use the #code category to discuss ideas and rough them out into features.
When you have an idea to discuss or a formal feature to propose, post it to #code. We'll discuss it as a community and use it to help shape the final implementation of the feature. Not all proposals will be accepted, of course, but either way there will be more background as to what direction the framework is headed. This information will also be useful to someone implementing the feature in future, as there's a lot of context contained within the discussion.
2. Once we decide to include a feature in the framework, create an issue for it on Github.
Features that we plan to add to the framework should be added as an issue on Github. We should include as much detail as required for someone to complete the work. A link back to the discussion should be added for easy reference. Once an issue is created, the related forum post should be locked so that conversation happens on the issue and any associated PRs.
3. Create and maintain a public roadmap for new features.
Documentation should exist for what features will be implemented in the next release. We'll maintain a prioritized roadmap for the next major and minor release, with all other features being listed in a general "backlog" section. Bugs will not be included on the roadmap, since I want to begin doing weekly patch releases once we hit 1.0. I'm not sure the best place to maintain a roadmap, but leaning towards the Github Wiki. Open to input here.
4. Post status updates to the (brand new) #status category, when it makes sense.
It often takes a long time to make progress on a feature, even though fairly consistent work is being done. I'd like to try providing status updates on the forum when it makes sense to do so. This will probably look different for different contributors. Personally, I'll be thinking of useful things I can share when I sit down to plan out my week. I might not post an update every week, but if there's something useful to share I certainly will.
That's about all I have to share. Eager to hear the community's thoughts. In the meantime, here are some things I'll be doing in the coming days:
- Creating posts for all the features that are planned
- Defining a public roadmap for the 1.0 release
- Cleaning up issues on Github
Big thanks to @jphager2 for getting me thinking about all of this.