In a previous blog post I asked feedback about adding an always visible action bar to Nautilus that integrated the floating bar info too.
It was very useful, as most of you confirmed our suspicions that it was too heavy, so we researched for a better solution for the goals we had: Make actions more discoverable, have good touch support and better pointer accessibility (not being able to access actions in list view anyone?).
Multiple people participated with constructive, well written and excellent feedback. Even more, they even provided high quality mock ups with ideas, to the point that I’m genuinely surprised.
So the goal of this post is for you to help me figure out what went well to have this constructive interaction! I have several factors in mind, could you share your thoughts?:
Was it because of using GitLab and its inline images support?
Was it the easy installation and testing of the work in progress with Flatpak?
Was it the exposure of the idea by being well written and formalized with goals, possible solutions, relevant art, etc?
Was the outreach for feedback early in the cycle with a blog post?
Was just the topic? i.e. you won’t feel as engaged with other ideas
Feel free to pick several of them or add more factors if those were the important ones for you (try to write down which one was the most important). I’m looking forward to repeat what was good for you all to participate in our next ideas. You can share your thoughts here in a comment or contacting me on irc.gnome.org in #gnome-hackers or #nautilus as csoriano.
Thanks!
PD: Feel free to try the solution we came up with and share your feedback & ideas in irc or in the issue.
I have been trying to improve our development experience by putting things together and create processes for our most common tasks taking advantage of the automation and features from GitLab and other technologies.
Today I’m going to propose the workflow for project & release planning for individual projects and for GNOME as a whole in the least time-consuming, most automatic and simple way I could come up with.
It’s my hope that this proposal will improve our contributor experience, reduce time spend on tracking issues, improve communication between teams such as design and engagement, increases exposure for PR, and finally, shorten the feedback & review cycle.
Goals
Reduce the need to explain our plans to just once. Including to our managers, release team, release notes writer, downstreams, users, other developers…
Attract contributors to work on what we consider priority for the project and help maintainers on make those happen.
Guide the current contributors in the short term and long term vision of the project.
Expose to the engagement team our plans to allow PR being done.
Shorten feedback cycle with designers and users.
Reduce the gap between GNOME release and downstream releases by allowing downstream better preparation upfront.
Manage effectively the explosion of issues and prioritize what’s actually wanted and doable.
Non goals
Workflow from written plan to implementation in individual tasks in individual projects. For example Nautilus does nothing, and others like ToDo, Calendar and Boxes use the Kanban workflow. The proposal written here is for the higher & overview levels.
Principles
Only three, but important:
As developers we focus on development, not paper work. This proposal should make things easier and less time consuming in the long term for you and the project contributors, not the opposite. Otherwise, I would need to revisit the proposal.
Short & concise, but complete. If there are requirements for a proposal, it’s not important if it’s written just with 2-4 words each, what’s important is that the list contains all of them.
Realistic. It’s better to be short on promises but deliver them than the opposite.
Proposal
Writing down project plans
One thing that applies to all of us is that writing plans down feels heavy. However it’s usually not about writing per se, it’s more about thinking what the format should be, what you actually need to write, etc. — Formalizing a plan is not easy.
To alleviate that, I created an issue template on GitLab to be used when you need to set up a plan. Copy it inside your project as “.gitlab/issues_templates/Epic.md”. It’s called “Epic” as a term that comes from Agile development. An Epic is a plan/task that goes across releases or development phases. Tasks that are achieved in one release are also fine, given our long 6-month cadence.
However, what’s important about epics it’s their meaning. They mean that the task fulfills three things:
Well scoped
Doable
Have an achievable end, when is considered done & completed
Specifically, they are not moon-shots. e.g. Improving Nautilus performance is not something that is well scoped and it doesn’t have a end date, therefore doesn’t fit as epic. In doing so, we avoid ideas that are unrealistic and also we don’t set the wrong expectations to other contributors, other teams, users and even more important, to ourselves.
You can see how it works for Nautilus in these two examples, adding a testing & performance framework & adding an action bar. And also we can consult epics across GNOME by an assigned label that I created for the GNOME group. It’s possible to see that the planning worked well for evolving the action bar design to something completely different than the original proposal thanks to the feedback and design contributions from several parties after exposing our plans in a easily reachable way.
It’s a fact that we cannot really handle all the issues that are reported to our projects, to the point navigating them stop making sense. Not only that, contributors & potential contributors usually don’t know on what to work or the priorities we have as a project. Or even worse, contributors providing patches that are not a priority so they are languishing for months with no review. I’m pretty confident to say that we lose contributions by not having clear plans.
So how about flipping the approach and pick the tasks/issues that we really care about and tag them? Something like a “backlog” of issues that fits well in the project, and even better, we can group them in two groups to expose our short-term and long-term project vision at the same time.
For that, we will use GitLab labels. They allow to query, edit and subscribe to the tasks assigned to them and display in a convenient UI. For that purpose I created two labels in the GNOME group, “Deliverable” and “Stretch”:
Deliverable: Short term vision. Planned for a moving target of aprox. 2 releases.
Stretch: Long term vision. Planned for a moving target of aprox. 4 releases.
When a new issue is created, read it and if it’s something really wanted, doable and scoped tag it and move on. The rule of thumb is that you only tag issues that either someone works on them or you will eventually need to. Later on you can select the label to query them and do “sprints” of development, which it’s quite useful to focus for some days on code rather than project management or bug triaging, and also you can point to that label to other contributors to know what they can work on.
Everything here is automatically handled, when tasks are completed or closed they will disappear from the list of open issues, and we can sort them by closed date or other values that allows other teams and people to check the status. We no longer have to track tasks manually or put some strange wiki attributes and we can query all plans across GNOME.
Note that we are not pinning plans to a specific release. Also note that these are a moving target, that means that if there are 2 releases that the project was not maintained, they “do not count”. Let’s not kid ourselves, we are a contributor driven project and with our past roadmaps we have seen specific dates being more a failure than an achievement.
With this proposal, we allow for a more flexible project planning where time is not as much a constrain but rather we just tell what the project vision for the future is and what our priorities are. Designers, contributors, engagement team, users and downstreams now can provide early design advice, contributions, PR exposure and feedback & testing respectively.
Now we can query these, both for individual projects or across projects at GNOME:
We have achieved quite a few goals so far with this proposal, but we are missing to help a few people and teams, including the release notes writer, video making creator and release team for each release, after all what gets consumed is what’s released.
Here is the only case that a specific date will be set, aka a “milestone”, that are also available for the GNOME group. A milestone is only added if it’s sure that the task/issue/feature/fix will happen for that release, most probably after it’s implemented and merged, or if it’s considered a true blocker. In doing so other people can rely on those items, and maintainers only commit to a specific date when they are sure the fix/task is gonna happen or has happened.
With this proposal poor souls *cough* Allan *cough* hunting maintainers down to get what major changes happened in the projects for release notes won’t be necessary anymore. And other poor souls *cough* Bastian *cough* trying to make the release video won’t be as frustrated. The release team can also track better the releases.
We now can plan and track tasks per project, and that’s already quite good! However, one of the questions we are missing to answer is, how about GNOME itself? Are there goals (or epics) for GNOME as a whole?
We had have a wiki page called initiatives in the past for that, and that was exactly its purpose. However, it was missing some bits to actually make it successful…
Apart of the missing automation of tasks and tracking, the way initiatives were defined were quite loosely, and most of the times there weren’t people in charge of making sure they happen. So the processes were quite cumbersome and the exposure of the initiatives were quite low, resulting on not very successful stories around that.
With those problems in mind, this proposal moves our initiatives effort to GitLab as a similar work flow than “Epics for GNOME”, provide templates for people to create them and automate as much as possible their tracking and delivery. For that purpose:
The project GNOME Initiatives has been created. The wiki with instructions is shown, and there is a template for creating an initiative.
Where the template will provide sections to fill, so there’s not need to think about the format and they will guide to provide useful information for others.
A label per each initiative is also created , so we can track the tasks assigned to a single initiative across projects. And last, we provide the same work flow and requirements as epics, so other people and teams know what to expect and can help make it happen or check the status easily.
For example, the first initiative created is to integrate Flatpak + CI for development of all core apps and newcomer apps. Quite useful! Go check it out as an example, and also take peek of it (not yet finished):
Initiative using the templateA wiki attached to the initiative with instructions to implement the tasks per each project
Conclusions
Big thanks to Jordan Petridis and Ernestas Kulik for being part of making this proposal to happen, I own them a drink!
In case it was not clear, I’m writing and doing all this work so neither me in the future or you have to, the whole point is that you just need to click 2 buttons and write 10 sentences and be done with it, if that’s not the case then I will need to improve the proposal.
Also, take this as an starting point, not as an end. There are not many new ideas here, more like trying to make them convenient, easy and straightforward once together. However believe me that I spent several days reading planning documentation and other issue trackers to make sure this is the best approach for GNOME. I’m looking forward to hear feedback and ideas from all and incorporate them, specially for the different teams at GNOME. This is going to be successful only if most of us at the core projects use it, and I think it will be beneficial for all of us.
And lately, consider that planning is not only about a maintainer and its code. A project at GNOME is also designers, is also engagement, is also release team, is also downstreams, and is also any potential contributor/tester/designer/marketing person that is not involved yet because we don’t expose our projects enough.
We are looking into adding an action & info bar to Nautilus. The background about this proposal can be read on the task where we put the main goals, prior art, different proposals and mockups, etc.
We are not sure whether this is the appropriate solution and whether the implementation we propose is ideal. In order to be more confident, we would like to gather early feedback on the current proposal. Also, we are looking for ideas on how to improve the overall approach.
The current proposal is being worked in a branch and can be installed via Flatpak clicking here (Note: You might need to install it the the CLI by executing `flatpak install nautilus-dev.flatpak` due to a bug in Software).
The current proposal looks as follows:
One of the concerns we have is about how visual heavy is to show the action bar at all times, in addition to the not very light buttons style.
One thing that could alleviate the heaviness is to style the buttons differently, and for that would be nice if someone that knows CSS plays a bit with it. To test your ideas, simply install the Flatpaked Nautilus, configure and open the GtkInspector with <ctrl>+<shift>+D, go to the CSS tab, and put the style you want to try out. To give some guidance, you have an example to make the action bar buttons flat here.
Feel free to comment here, reach me on IRC at #nautilus on irc.gnome.org as csoriano, or send an email to nautilus-list@gnome.org.
I will write an update in this blog with the outcome when we achieve some more advanced proposal with the feedback we have received.
I’m looking forward to hear your ideas and thoughts!
I know some fellows doesn’t read desktop-devel-list, so let me share here an email that it’s important for all to read: We have put in place the plan for the mass migration to GitLab and the steps maintainers needs to do.
In this post I will explain how GitLab, CI, Flatpak and GNOME apps come together into, in my opinion, a dream-come-true full flow for GNOME, a proposal to be implemented by all GNOME apps.
Needless to say I enjoy seeing a plan that involves several moving pieces from different initiatives and people being put together into something bigger, I definitely had a good time ✌️.
Generated Flatpak for every work in progress
The biggest news: From now on designers, testers and people with curiosity can install any work in progress (a.k.a ‘merge request‘) in an automated way with a simple click and a few minutes. With the integrated GitLab CI now we generate a Flatpak file for every merge request in Nautilus!
In case you are not familiar with Flatpak, this technology allows anyone using different Linux distributions to install an application that will use exactly the same environment as the developers are using, providing a seamless synchronized experience.
For example, do you want to try out the recent work done by Nikita that makes Nautilus views distribute the space between icons? Simply click here or download the artifacts of any merge requestpipeline. It’s also possible to browse other artifacts, like build and test logs:
Notes: Due to a recent bug in Software you might need to install the 3.28 Flatpak Platform & Sdk manually; this usually happen automatically. In the meantime install the current master development Flatpak Nautilus with a single click here. In Ubuntu you might need to install Flatpak first.
Parallel installation
Now, a way to quickly test latest works in progress in Nautilus it’s a considerable improvement, but a user probably don’t want to mess up with the system installation of Nautilus or other GNOME projects installation, specially since it’s a system component. So we have worked on a way to make possible a full parallel installation and full parallel run of Nautilus versions alongside the system installation. We have also provided support for this setup in the UI to make it easily recognizable and ensure the user is not confused about what version of Nautilus is looking at. This is how it looks after installing any of the Flatpak files mentioned above:
We can see Nautilus system installation and the developer preview running at the same time, the unstable version has a blue color in the header bar and a icon with gears. As a side note you can also see the work of Nikita I mentioned before, the developer version of the views now distribute the space of the icons.
It’s possible to install more versions and run them all at the same time, you can see here how the different installed versions are found in the search of GNOME Shell where I also have the stable Flatpak Nautilus installed:
Another positive note is that this also removes the need to close the system instance of the app when contributing to GNOME, it was one of the most reported confusing steps of our newcomers guide.
Issues templates
One of the biggest difficulties we have for people reporting issues is that they either have an outdated application, the application is modified downstream, or the environment is completely different as the one the developers are using, making the experience difficult and frustrating for both the reporter and the developer. Needless to say all of us had to deal with ‘worksforme‘ issues…
With Flatpak, GitLab and the work explained before we can fix this and boost considerably our success with bugs.
We have created a “bug” template where reporters are instructed to download the Flatpaked application in order to test and reproduce in the exact same environment and version as the developers, testers, and everyone involved is using. Here’s part of how the issue template looks like:
When created, the issue renders as:
Which is considerably clearer.
Notes: The plan is to provide the stable app Flatpak too.
Full continuous integration
The last step to close this plan is to make sure that GNOME projects build in all the major distributors. After all, most of us are working both upstream in GNOME and downstream in a Linux distribution. For that, we have made a full array of builds that runs weekly:
Which also fixes another issue we have experience for years: Distribution packagers delivering some GNOME applications different than intended, causing subtle but also sometimes major issues. Now we can point out to this graph that contains the commands to build the application as exact documentation on how to package GNOME projects, directly from the maintainer.
‘How to’ for GNOME maintainers
For the full CI and Flatpak file generation take a look at Nautilus GitLab CI. For the cross distro weekly array additionally create an scheduled pipeline like this. It’s also possible to do more regularly the weekly array of CI, however keep in mind the resources are limited and that the important part is that every MR is buildable and that the tests passes. Otherwise it can be confusing to contributors if the pipeline is failing for a one of the jobs and not for others. For non apps projects, you can pick a single distribution you are comfortable with, other ideas are welcome.
A more complex CI is possible, take a look at the magic work of Jordan Petridis in librsvg. I heard Jordan will do a blog post soon about more CI magic, which will be interesting to read.
For parallel installation, it’s mainly this MR for master and this commit for the stable version; however there has been a couple of commits on top of each, follow them up to today’s date (19-03-2018).
For issues templates, take a look at the templates folder. We were discussing here a default template to be used for GNOME projects,however there was not much input in there so for now I imagined better to experiment with this in Nautilus. Also, this will make more sense once we can put a default template in place, this is something GitLab will probably work on soon.
Finishing up…
On the last 4 days Ernestas Kulik, Jordan Petridis, and me have been working trying to time box this effort and come with a complete proposal by today, each of us working in a part of the plan, and I think we can say we achieved it. Alex Larsson and other people around in #flatpak provided us with valuable help. Work by Florian Mullner and Christian Hergert were an inspiration for us too. Andrea Veri and Javier Jardon put a considerable amount of their time into setting up an AWS instance for CI so we can have fast builds. Big thanks to all of them.
As you may guess, this CI setup for an organization like GNOME with more than 500 projects is quite resource consuming. Good news is that we have some help from sponsors happening, many thanks to them! Stay tuned for the announcements.
Hope you like the direction GNOME is going, for me it’s exciting to modernize and make more dynamic how GNOME development happens, I can see we have come a long way since a year ago. If you have any thoughts, comments or ideas let any of us know!
Becoming a maintainer of a FOSS project is not easy. It requires much more than just code skills. It’s about responsibility, product management, vision, community and hard work in long-term.
Becoming a maintainer of a FOSS project like Nautilus is even harder, it requires a sense of what being used by millions of people and delivering to business entitles. It also requires understanding the complexity of a file manager, and the old code that lies behind.
Now, becoming maintainer of a project that already has a maintainer working full time on it… that’s a different level.
Ernestas started contributing more than 2 years ago as a community member on his free time. Did major code work like porting Nautilus to Meson, make Nautilus work on Flatpak, improved search, improved operations, took the lead on fixing all deprecations (we had many!), worked on a prototype for a new cache/operations backend, dig into other libraries deeper on the stack to fix something that was visible in Nautilus, and many other things. What was most noticeable is the quality Ernestas strives for in all these contributions.
However, the above would make him “just” a good software programmer, the important part that makes him a good maintainer were other actions. Ernestas took the lead on newcomers bugs review/assignment, took the lead on legal matters like the GPL3 vs GPL2 issue we had with extensions, reviewed code from other contributors (including me), worked without dilation on critical issues in a timely manner, worked on tasks important to our vision, engaged in bug reports with good communication, helped with project direction, considered all sides and the big picture when taking decisions and last, all of this with excellence. If you ever wondered what someone has to do to become a good maintainer/co-maintainer, here’s the answer.
So without more dilation, welcome Ernestas in his new role as co-maintainer, go on IRC and congratulate him 🎉
We have been discussing our plans with the desktop part of Nautilus for quite a bit of time and in this blog post I’ll explain them.
Context
Nautilus had have a feature called “the desktop” which adds icons on the background of the user workspace, similar to Windows.
The desktop was disabled for the default experience when GNOME 3 came out now 6 years ago, and so far has been mostly unmaintained. I spent around 3 months of work two years ago to try to save it somehow and did a rearchitectural work to try to separate the desktop from the Nautilus app so it won’t affect Nautilus development, and while it achieved some degree of separation, it didn’t achieve its main purpose and unfortunately brought even more problems than we had before. Now it has got to a point where the desktop is blocking us deeply in basically every major front we have set for future releases.
Also we notice that users rightfully have expectations for the desktop to work decently, and we acknowledge this is far from the reality and we are aware that the desktop is in a very poor state.
If you are interested in more technical details of the issues with the desktop implementation you can read them here.
With these points at hand that have accumulated over the years, we are at the point that we need to remove the desktop code inside Nautilus for Nautilus 3.28 to move forward with Nautilus development. You can check the branch with the removal work here, if you look you will see that the desktop is composed by more than 10.000 lines of code given the complexity to create it with the technologies that were available in 1999 (yes, the code is that old :)).
Solutions
With removing the desktop code from Nautilus we have considered these three options, keeping in mind that the ability to have icons on the desktop can be provided by other projects than Nautilus:
Fork Nautilus desktop, one project being the desktop and the other being Nautilus app. This however doesn’t fix anything at all, the issues will still be there and I’ll be very sad for anyone that has to maintain it.
Use Nemo desktop. This is, as of today, a more featureful desktop than the one in Nautilus, so probably it’s the best short term solution. It however has similar problems than the ones Nautilus desktop faced. You can read how to install it here.
Make the desktop icons a Shell extension.
Proposal
The best option to of those three to move forward is to integrate it in a GNOME Shell extension. Doing what nautilus desktop was doing in an app (Nautilus) while trying to be part of the compositor (GNOME Shell) was a big mistake, and it’s one of the major issues. It’s important if you understand some technical terms to check the issues we were facing to understand how we agreed to this proposal to be the best option. This is true even more nowadays with various technologies being more in the isolation, privacy and secure side (Wayland, sandboxing, etc).
A nice thing of doing a GNOME Shell extension is that it opens the path to a more dynamic desktop workflow, and the good news is that the prototype that we have in place already has fixed one of the oldest bugs we had in the Nautilus desktop, proper multimonitor support!
You can check the extension prototype here (very early prototype). While this extension is the way forward, the time I can spend on it is limited since upstream wise the desktop pattern didn’t make much sense for long time now. So I encourage anyone that knows JavaScript or wants to learn JavaScript and likes the desktop workflow to make it happen, I’ll be there for helping any contributor making code alongside and to expand on new ideas for the desktop workflow that those that like it have in mind. You can check few points that would be nice to have for a first release here. Ping me on IRC if you are interested on it.
Who will experience a change
For those using distributions with desktop pattern workflows (e.g. Ubuntu), I don’t expect anyone to be affected, if those distributions/projects derived from upstream design decisions based on their own design decisions, I expect they will hold into those patterns and provide a desktop workflow in one form or another.
If your distribution didn’t ship a desktop by default and you were using Nautilus desktop, you can check out the options proposed before to continue using a similar workflow.
Fruits of the removal
The question is, when are the fruits of the removal of the desktop going to be noticeable?
Thanks to the removal of the desktop code we are now free to move forward with the complete rework of the Nautilus backend for 3.28, probably the biggest rework ever done in Nautilus. This will allow heavy searches to not make the UI get stuck and to be resource balanced so you could do multiple searches at the same time, it will also provide proper thread handling, ability to pause operations, ability for performance stats (and finally being able to do performance improvements), easy tweak for operations resource balancing, and more.
Another major work that thanks to the removal of the desktop code we can move forward with is the new views that I talked about in a previous blog post. We won’t make it for Nautilus 3.28 since it requires gtk+ work too, but now we can continue improving it in the Nautilus side and hopefully for 3.30 we can finally move to the next generation of content views.
And finally, this also allows for Nautilus to be ported to gtk4. This is really good news in various fronts for Nautilus; hopefully gtk4 stabilizes a little bit more and we can port to it for Nautilus 3.30.
I want to thank Ernestas and Antonio to work on these big changes and the help overall with Nautilus!
