I want to start doing these updates relatively regular, so anyone interested in contributing code to our various projects can know what’s going on, and what contributions we’ll potentially be accepting or holding off on.
I’m in the process of developing some workflow functionality for a customer. This project will bring the CLI up to date with the latest API, as well as support a writing workflow that maintains all blog posts as local files, with a simple syncing mechanism. All of this work will be included in upstream and released in v2.0.
This repo has a few open issues and pull requests right now. I’m holding off on merging them until they’re needed in the course of the current client project, or after. I need to make sure the CLI accomplishes our project goals before looking back to the community.
All of this also goes for the go-writeas library, which is heavily used by the CLI. All merges are pretty much paused until this project is done.
I’m working on narrowing down the functionality needed to launch a version 1.0 of WriteFreely. The goal is to include only what’s absolutely needed to make it ready for production use, so we can do a wider launch this month (February). Please leave your feedback on the thread I just linked if you have any input.
Help wanted: Feedback on what to include. Development on final decided features.
As part of the customer work I’m doing on the CLI, I’ll also be releasing an open source import-from-WordPress tool. I’m developing this in the open from the start, but it will be extensively tested on the customer migrating their blog from WordPress (and may include some changes particularly for their use-case).
Love the idea of a regular development update . Am I correct in the assumption that the big customer projects binds almost all time at the moment and you (and/or team) completed the project, you will be able to focus more on improving the write.as service, and add new features etc? Or is that completely separate. Just wondering if I understood correctly, language barrier and all .
I saw several Kanban like project planners for the project (I think on trello.com and another one). Which one is the most recent? For example, if I wanted to see if any feature requests / improvement ideas made the cut and are considered for implementation? Is there a way the users can see that kind of thing?
I’m always juggling several things at once, but yes, the customer projects (and any potential critical bugs) will generally get done first – particularly with our open source projects. It doesn’t mean normal development / improvements won’t happen at all – just that they’re a bit lower priority. And, of course, many of these paid projects are for features that will improve the platform for everyone
As for the official project planner, this WriteFreely board and the Phabricator site in general are what we actually work off of. Please feel free to create an account there, too, especially if you want to give input or contribute code.
I’m trying to move all of our general planning to that site (instead of Trello) so everyone can see what exactly is planned and where it’s at.
Ah cool. That makes sense to move it all into one board. Unfortunately I dont know anything about iOS or Android development, and Ruby and I are a bit on the war path ever since I tried it . I am an Automation Engineer / SRE by trade, so if it is code, it would be probably some integration, automation or help with some project management.
The most interesting point to me, personally, right now, would be the implementation of a few features. Also people have some many great ideas here in on the site. I would love to see some of them become features. Of course, not everything can be implemented. But it would be cool to see a lane called “Suggested Features by Users” or “Accepted Feature Requests” that shows features accepted by you and your team. So then people could take a look and see if their feature is considered to be implemented, and if it is something that will be integrated in the far future, or if it is already scheduled for a quarter or a year. I really like the idea with the quarterly “sprints” on the write.as board.
In general I am curious about the structure of the project:
It is my understanding that the focus is less on the Write.as service, but more on the WriteFreely OSS version, which features will then also be integrated into the Write.as service after they are merged into the WriteFreely code base? And with “Write.as” service I mean the hosting and paid service offering.
Would that understanding be correct? Or would it be the other way around? I mean, it would be a good selling point for the service to get features out to paying customers first, and then release them into the OSS version after a retention time.
Sorry about all those questions . I am looking for quite some time now to find a blogging solution or a service that I do not have to host myself, that is lightweight, has all the features that I want, and where I am not customer 49358439345 of a big faceless corporation. The write.as / snap.as combo is almost perfect in that regard, but also only almost.
So I am very curious about this project and I am eager to see where the path of the leads to. If that makes sense.
No worries! I’m glad we’re pretty close to what you’re looking for
That’s a great suggestion about showing which feature requests have been accepted. Since we’re gathering most input here on the forums, I’m going to see if we can somehow get this functionality on the forums (I think I’ve seen other people do it). As for the quarterly sprints, I’d love to do them with Write.as and everything, but it’s hard to plan out an entire year that way and stick to it, especially for small items. What I’m trying for now is planning a quarter or two at a time, and only for the larger items. But maybe that’ll change in the future.
As for the structure of the project, we try to keep as much of the open source side as possible open to everyone, which is why it may seem like that’s where the focus is. But there’s a lot going on behind the scenes that we don’t publicize, and indeed the Write.as service is where our focus is. Everyone on the platform ultimately drives development on WriteFreely.
Especially with some of the larger changes planned, like extra customization that people have suggested, integrations, plugins, etc. we will be releasing them on Write.as before WriteFreely. Besides being a good selling point, mostly it lets us get a new feature out to tens of thousands of people instantly, see how they like it, and then quickly improve it if needed. It’s much harder to get this feedback loop with the open source version.
What you said about the feedback loop is so true. And also about the quarterly structure of the board. I know it is hard to plan out every little detail, but in my opinion it doesn’t need to be that detailed for the public.
Quarterly or even bi-yearly would be more than OK for me. At least for features. So “feature X is planned for Q3 2019” or “Feature Y will be released in the second half of 2019”. But to get some sense of progress, as users don’t usually get to see what is going on behind the scenes – it even helps sometimes to read what is blocking the implementation of a certain feature.
Thank you for taking the time to explain a bit about the project background. Much appreciated!
. Am I correct in the assumption that the big customer projects binds almost all time at the moment and you (and/or team) completed the project, you will be able to focus more on improving the write.as service, and add new features etc? Or is that completely separate. Just wondering if I understood correctly, language barrier and all 
.
. I am an Automation Engineer / SRE by trade, so if it is code, it would be probably some integration, automation or help with some project management.
. I am looking for quite some time now to find a blogging solution or a service that I do not have to host myself, that is lightweight, has all the features that I want, and where I am not customer 49358439345 of a big faceless corporation. The write.as / snap.as combo is almost perfect in that regard, but also only almost.
