Ah, sorry, I had managed to miss this. Sorry about that.
Unfortunately not. And in fact, none of the times on the doodle work for me.
But I would also like to manage expectations here. I don’t think it’s possible or a good idea to try to figure out the design ideas for the next Graphryder in a one-hour meeting. I think we really need to kick that work off with something like a one-day session. Of course, we could start with a one-hour exploratory session to set a course, but I do not expect us to make a decision on things like:
When designing software in the past, a good starting point has been to plan for a two-day design sprint. Most of the work is done on the first day, then slept on, and solidified on the second day. For this upgrade of GR, I think we could fit this into one day. We start with a bigger team in the morning, including the wider ethnography team. We then move into a smaller team in the afternoon - probably me, @alberto, @amelia and @matthias.
Are we up for something like that? I could facilitate the design session.
Works for me… but then it does not have to work for me, it has to work for the developers.
It could also be a “lightweight” thing: a high-level agreement on what we want to achieve, and then it’s down to Github issues. But I am open to almost any format.
Mmmh let’s keep realistic, I’d say. We don’t have the budget to implement anything that deserves a two-day design meeting. We’d only get everyone’s hopes up to be disappointed later.
What I wanted is a meeting to map the existing functionality onto the new implementation using Discourse and Redis and VueJS, accommodating wishes as we can but without redesigning everything. Re-implementing, even in another language and framework, is most often three times faster than developing anything from scratch because you know that it can be done and how.
We’d take care to keep the new implementation flexible and extensible for the times when we have budget to extend it, but that is not right now. If you still want to do a “big vision” design meeting, please go ahead, but be aware that it will inform next year’s development as that: a vision, not a direct plan for action.
That leaves some questions to answer. For example:
There is no “new implementation” yet. What we have are really just some early experiments that are promising but not more than that. If we want to map anything onto that new implementation, we need to first build that implementation.
If you recall, the work on the new GR backend halted because the tests were breaking the platform in production, but we didn’t have a staging server to work on and I wasn’t able to set one up with the existing documentation. That’s still where we are in terms of continuing the experiments with RedisGraph.
And this is exactly the sort of work that requires foresight, which requires time to achieve.
This budget that we have now is ultimately not on my table, so I’ll take the backseat if you want to go another way. It’s not wise for me to push a direction that I ultimately have little influence over holding.
So, is there an agreement on how we are proceeding? Scheduling the initial call next week and depending on that deciding if a longer session is needed? If that’s the case I’ll set up a new doodle.
Oh sorry Martin! the invitation in the calendar is for the biweekly happening next Wednesday, 21/10 at 17h, on the topic of the upcoming Horizon Green Deal calls. Hope you’ll be able to make it then…I will prepare the agenda soon.
After talking with Hugi and shuffling some things around: Hugi is welcome to facilitate a longer design event for the future Graphryder application. I’d participate at least most of the time to provide the software architecture / system integration perspective. Over to @hugi to propose a suitable time. I’m available next week, should it be then.