This week I started eight threads on the Qt dev mailing list, and it’s not because I like writing essays. This blog post is because I like writing essays. I just have a lot to talk about, and in classic meta-cognition style I’d like to talk a lot about why I’m talking a lot.
First of all these discussions aren’t anything new. QML has been developing for a long time, and at every step it helps to discuss the ideas before development. Standard group development practice it just happened internally at the Brisbane office instead of on mailing lists. Then the Brisbane office was closed, and some of us moved across the Pacific, so it happened on email threads between us instead of in person. What changed is that at Dev Days last week I got the impression that other people are interested in QML development now. As much as I love the community development model that the Qt project has been building up, I never got the feeling other people were working on QML. QML users have been sighted before, sure, but they’re never interested in its development. There’s a big gap between people using the old version and people already planning how they’ll use the new version. In the former case you still engage with the users, but the model is more one of seeking feedback to fuel later discussions within the team. To really engage in the initial discussions requires users or developers who are not only using the current version, but who are actively looking towards using the next version when (or before) it arrives. At the boundary of the new major version, we’re in a situation that really brings hope to that scenario. So there might be people interested in contributing who are actually in a context to usefully do so. I hope they’re on the dev list. (That last comment is not disparaging of the existing dev list users, but that list is traditionally C++ users – and the only announcement that it’s now open for QML talk was on the C++-user-populated dev list.)
Now that there is a significant interest in QML from the development community, I would say that means QML discussion must happen there. Not all discussion, there’s still a lot going on in the #qt-qml channel in real time, but it should have precedence over the private email threads. Qt and therefore QML development is done in the open, a model that we shouldn’t try to subvert. Once there is community interest and involvement, it is counter-productive to be holding the discussions behind closed doors. That leads to interested contributors contributing the wrong thing; and I don’t just mean wrong by my standards. Already in the existing discussion threads some of my own proposed APIs have been shown (not conclusively mind you 😉 ) to be “the wrong thing”. That’s just iterative development at work, but if I just went and implemented one of these APIs then maybe I’d have taken it to code review only to have someone say “wrong API. we don’t want this in Qt”. There’s a real risk of this happening without proper coordination, because if people don’t know the direction Qt plans to move forward in they might do work which is contrary to that direction. An example might be if someone tried to make QtQuick 1 elements public C++ API back in 4.x, when we always knew that those C++ classes were not going to be our forward direction. Fortunately back then no-one really thought about the development of QML (not that it stopped them posting to the mailing list asking for public C++ APIs 😛 ). This also speaks broadly to the importance of planning APIs before starting the implementation. I’m not talking about a waterfall model approach, but you need generalized agreement on where you want to go. That means knowledge of what functionality the API is to provide, what API would ideally fulfill all usecases, and as much feedback as possible from low-cost “text mockups” (writing a sample API/useage). After iterating on that quickly, you can start to expand the iteration to prototypes which can iteratively expand to be a full implementation or just iterate through more prototypes or even back to the drawing board depending on how it goes. Talk is cheap (says the person who’s spent all week writing), so it’s the fastest way to iterate as a group to reach the best outcome. And by keeping the whole group in the loop, we move forward together on all aspects of the implementation because we know what aspects are affected (like are they really going to replace QSettings anytime soon?).
There is an important conclusion which is the intersection of community, and doing design before implementation: work becomes available. It’s always nice to see a guy who wants to make a contribution but doesn’t know where to start, however they’re rare and tend not to be familiar with the code. So this isn’t really about the use case of someone just wanting to do any easy bit of work for the project that becomes available (FYI: That qml binary looks like it’s a really easy bit of work that just became available 😉 ). The Qt project community is formed because they all use Qt and they all want to do things, and sometimes the best way of doing those things is to fix or improve Qt. You can work around the issues sometimes, but for those people wanting to see something happen the easiest path towards that is to do it yourself. Open discussion about the open QML issues means that anyone affected by them has a clear vision of the path to do it themselves within Qt. By providing a clear path in some cases it will be easier for a Qt user/developer to implement it in Qt and then use the result than to implement it themselves on top of Qt, and watch everyone else do the same thing in ‘slightly’ different ways. Some topics, like the import control, are things that are very hard to do outside Qt but very easy to do inside. Some topics, like the runtime, are things that are easy to do on top of Qt but there’s real value in everyone having a common implementation instead of hundreds of different variants. And other topics, like full-fledged enum support, are syntactic sugar that I don’t use and so will never implement myself – but could be done in a way that’s right for the language and so I will help someone else do it properly if they really want to do it. As the person who started the threads there is some expectation that I’d take the lead on implementing those features, and I will if no-one else steps up. But with so many features on my plate (plus performance optimizations making QML on BB10 so fast that I can barely stand to use my Nexus 7 anymore!) it may not get done soon. So remember that in a do-ocracy, if you want something done then you should just do it. Open planning and discussions make that the simple question of putting in effort, not the complex questions of “does the project want this?” and “how should this be done?” which are handled relatively easily if we all just discuss it together.
Combine that logic with a backlog of issues that have been sort of discussed but not nailed down already, and you’ll understand why I’ve been spending so much time on the mailing list (and will spend more, those eight were just the start so that it’s in manageable pieces). If your reading or writing skills aren’t good enough to handle that much email in a reasonable time, go take a class. The only person holding you back is yourself. Before I make anyone feel bad about themselves, keep in mind that I’d say a week is a reasonable time for this mailing list; I’m only keeping up with it daily because I’m really interested in all these discussions 🙂 .
Be First to Comment