Th Sprint series comes out every 3 weeks or so. Focus will be on the apps I maintain (Calendar, To Do, and Settings), but it may also include other applications that I contribute to.
The second sprint was great for GNOME To Do and GNOME Settings! GNOME Calendar is going through a big rewrite, and there is nothing demo-material this week.
GNOME To Do: Archiving task lists
Let’s start with GNOME To Do, since it received an exciting new feature.
The focus during this sprint was on archiving task lists on GNOME To Do.
This was a long-time request, and something that I myself was missing when using To Do. Since it fits well with the product vision of the app, there was nothing preventing it from being implemented.
Selecting this feature to be implemented during the week was a great choice – the task was self contained, had a clear end, and was just difficult just enough to be challenging but not more than that.
However, I found a few issues with the implementation, and want to use the next round to polish the feature. Using the entire week to polish the feature might be too much, but it will give me some time to really make it great.
GNOME Settings: Every Detail Matters
Thanks to the help of Allan, Tobias and Sam, we ran a successful session of Every Detail Matters, focused on GNOME Settings. The tasks ranged from small to big ones, but we tried to scope it to fit a single week of work. Here are some quick highlights of the resulting work:
I’m happy to say, it worked very well! In fact, way better than what I was expecting. We had two new contributors helping out, two long-term contributors leading the development efforts, and three designers involved.
It was not perfect, though; after doing a retrospective, we identified various points where we could have done differently in order to increase engagement, reduce stress and improve how design is made before development starts.
GNOME Calendar: Improving the calendar management dialog
This time, Calendar is going through another massive rewrite. This is not a single-week task, and I believe I correctly assessed that it would take 2 weeks to complete it.
What is being rewritten is the calendar management dialog. This is some code I wrote back in 2015, and my older self is deeply dissatisfied with the decisions my younger self made. Like, not breaking up the code in sweet small digestible chunks. Really, if you plan to maintain an app, pay attention to how your code is organized.
This is still ongoing work and I will leave the demo for when it is ready.
Still Open Questions…
Running the Every Detail Matters session was a fantastic experience, but also made me wonder about ways to deal with dealing with contributors assuming tasks in free and open source communities.
Suppose you are the maintainer of an app, and a first time contributor claims a task; you know you would finish that task in less than an hour, but you still want to give the contributor the chance to, well, contribute. Turns out, the contributor takes a long time to finish the task, blocking development.
What’s the best way to handle this scenario?
The only alternative that comes to my mind is: do not allow first time contributors to have tasks assigned. Instead, ask the new contributor to simply fix the issue they want to fix and send the contribution for review; don’t try and task pre-assigned.
I like this alternative because it matches my experience as a maintainer; the vast, massive majority of new contributors do not follow up with their contributions, leaving maintainers and other contributors hanging. Thus, I think that not allowing new contributors to block development is positive.
Do you, dear reader, have any other suggestions or ideas about it? If you do, I would very much like to know about it.
Leave a Reply