Current development team status

Hi everyone,

I just want to give you a bit of feedback from the inside of the development team. We’ve not forgotten you.
Umikaze 2.2.1 RC3 is intended for release this week. A link will be provided in its own thread when it’s out. (I’ve got an idea I’d like to try now that we have a proper forum)
However, there are a few issues that I’m sure you’ve noticed, without necessarily understanding the reasons for them. I hope some of this helps to clarify that, and if any of you can help us address any of them in any way after the explanation below - please speak up. We need help - even if it’s just to give us a pat on the back to keep the energy to move forward.

What I’m going to describe are my feelings and my understanding of the team and its interaction around the software that we’re building for Replicape and Revolve.

Over the last half year I feel like I’ve seen the pace of development diminish. Part of that is my fault - work has been picking up and leaving me with a lot less time to contribute and organize meetings and the like. Part of that is also that a number of people wanting to contribute ended up not sticking around. I can’t point out a single reason for that, but I think the main factors involved were: messy/missing documentation, lack of inter-developer communication, and potentially a feeling that the core developers weren’t interested in what was contributed.

The lack of structured and comprehensive documentation is an ongoing problem - we had an attempt made by an open source consultant who passed by to try and make the documentation more modern using the github.io pages system. Problem is, when we switched branch names and development process to accomodate more developers, we couldn’t update the scheme to match. We had no ownership over the pages and they were left to rot in the corner. I recently reverted all the links to be back on the Wiki. The content there is easier to update and centrally located, with the ownership and administration rights being clear. Not as pretty, but definitely easier to structure from an admin point of view. If you have ideas or want to see github.io pages again, please let the dev team know - we’re not against the principle, just that particular implementation was poorly managed. However we’re still missing contributions on the documentation side. Mostly on user-guides and general software configuration. If you feel like trying to help us fix the documentation, please get in touch - we’ll welcome the help!

On the inter-developer communication, part of that was the lack of publicly visible channels to do so. Most older open source projects have a publicly-available developer mailing list, forum or something similar. We have a Slack channel. The Slack, I feel, was partially hidden as long as we were on Github and Google+. Now that we’re here on MakerForums, the header clearly shows the self-invitation link to our Slack, and I think this may help expose it. Another thing is that I’m now trying to organize more regular mini-telecons between the core developers, with the intent to eventually make those regular and publicly available events. This way anyone can come in and listen as to what’s being worked on, debugged, fixed, and what coordination needs to happen. We’ll see how that goes - for now if we can get the main core developers talking to each other about what we’re trying to work on and how to align our efforts so we stop stepping on each others’ toes, I’ll feel satisfied.

Finally, regarding development contributions… I need to work with the core developers to write a proper “how to contribute” page, which is essentially developing a formal procedure for setting a timeline on responding to pull requests within a reasonable time frame. Once we have this, I will do my best to enforce the policy rigorously, so that any outside work submitted doesn’t fall by the wayside. That same page will also encourage contributors to join in on the next developer telecon after they open their PR, so it can be presented and discussed. From experience, it’s often more difficult to forget about something if there’s a face and name behind it. So if we’ve let you down before (looking at some commits by @Daryl_Bond for example), I am sorry and I hope we can address these issues in a positive and proactive manner.

I let this all out here because, after reading about the Linux Mint team’s depression on the eve of their new release, a lot of it rings familiar. We’re running out of steam, and I don’t want to see that happen. Revolve is coming out soon, and we should be picking up speed, not drown into depressive inaction. This is as much the community’s project as it is our own.

3 Likes

On Friday, I posted a “candidate” for the Umikaze-RC3 which is itself a candidate for the Umikaze-2.2.1 release. In testing, a few issues with the build of the distribution were noted. A new candidate was generated. Note that all of these image files utilize the same versions of the printer controller (Redeem), the web interface(OctoPrint) and the screen UI (Toggle).

As noted, “in content, should be pretty close to the code for the Umikaze-2.2.1 release. We still have a couple of issues before we present the next, and hopefully final, RC distribution before the release. Things are working better than ever. But we always need your feedback. Enjoy …”

And the link, Umikaze-2.2.1-Shiloh

Since it is a pre-release version, if you flash this image, we expect that you will be able to convert to the release behavior without reflashing. Instructions will be provided at the appropriate time.

This is the latest, and best, version of our code. We need testing and feedback to complete a quality release.

I encourage everyone to give it a try …

2 Likes