Brainstorming on features

Hi Italo,

You call out the ESC here: Sorry, but I give up, so please allow me to react to that here. :slight_smile:

Unfortunately I don’t think we have 150 developers who just wait for somebody to tell them what to do.

The ESC - provides a meeting point to resolve conflicts and to report on the current status of some efforts. Occasionally it gets involved in some technical conflict - it doesn’t strategically plan features, and has no way to tell others what to do. Even with action items, I always ask the person in question if they’re OK to do XY before giving them the matching action item when I lead the meeting.

I guess part of the trouble is that most users have good ideas on what to do, but compared to that, there is only a small amount of developers who have the time to implement some of them.

I believe that would require the ESC to do some kind of management of developers, while it’s a coordinating body in its current form.

We don’t tell people what to do because most developers are either volunteers or they work for some company. Volunteers usually contribute because they have some own need they want to fix. Developers working for a company typically have their customers, so they spend most of their time on their customer’s need. And the hope is that the result is generally useful for everyone.

Based on this, it sounds like a bad conclusion that the ESC would control anything – the idea is that we coordinate the already happening work, to have technical input from everyone involved. If somebody would question this, please join one of the ESC calls and you’ll see it yourself. Perhaps the ESC is a friendly place because whenever there is a task to be done, all we can do is asking nicely & hoping.

At least I personally would never try to get rid of you, and I assume that most developers would agree with that, so please try to avoid such general statements, it’s not motivating.

I guess one big difference compared to 2011 is that TDF now has people and money to have a real impact on how libreoffice is improving. TDF developers can add features, TDF has the money to run tenders – the board can vote on budget and decide what feature development to fund an so on. I would hope that in case you’re not happy where TDF is heading with libreoffice development, these tools could help to adjust that direction.

What do you think, what would be a way to get more, constructive feedback from non-developers to have an understanding what people want as next features? Perhaps some kind of brainstorming session?

Heiko already runs the design meetings and does a nice job of triaging those ideas: some can be just done, some need engineering input and he lists those bugzilla bugs on a weekly basis, takes it to the ESC. When somebody instantly has an idea, they can comment on that – otherwise it’s always possible to comment in bugzilla later. Perhaps the same could be done in other areas of the project.

To sum up, sounds like the problem is that you find the process of adding new features to libreoffice too closed – what do you think, how should we improve & open up this process more?

And then I guess the next step would be for TDF to invest more in actually implementing some of those good ideas.

Thanks,

Miklos

2 Likes

MiklĂłs is right. ESC is the wrong address here. What Italo really wants is to collaborate with the design team.

On the part of volunteers, we rely on their generosity and it is top priority for TDF staff to support them and reduce the boring and tedious side of things. When there is mutual understanding, it’s not really about telling people what to do rather than facilitating common goals.

Internships like GSoC and Outreachy are good opportunities to reach all types of goals, from smaller features to generic quality improvements or even approaching bigger strategic goals in a bite-sized way. There are always possibilities for non-developers to help with these. The mentors gladly welcome help in defining the projects, giving feedback on implementation along the way and reporting issues after completion. Just last week I reported three issues for a 2024 GSoC project that is still in need of polishing.

About facilitating strategic goals, TDF staff is indeed starting to be in a position where we can make a difference. Personally, I keep an emphasis on the UI. The respective code in general should be such that it is easy for developers to manipulate the UI. It is very counterproductive, if after coming up with some barely working result, a new developer is exhausted and would rather disappear than apply the needed beautifications. The required renovation work is under the hood and not particularly glamorous. I am glad that we are able to build upon and continue Caolán’s monumental work that originally targeted a specific Linux UI backend.

1 Like

Hi Miklos,

like you I am very sad to see Italo giving up – however, I can very much empathize esp. with the given rationale.

That is a very negative takeaway, though I agree that the ESC is not really “controlling” anything, rather than coordinating – at least while I was still attending years ago.

I fully support Italos vision here – but think tendering is a fundamental obstacle for this. Brainstorming sessions like those @italovignoli is aiming for are – with rare exceptions – only possible under time and material contracts, not via fixed price tenders. Note the scenario Italo describes – working with company employees are similar in that. Would ecosystem companies or even new contractors be participating in such a setup? I dont know. It likely depends very much on how professional TDF implements it.

The other part here is: What should be the source of requirements for work sponsored by TDF on LibreOffice itself? I think that should be the trustees (vetted and budgeted by the Board). The detailed execution of these requirements could be performed by a PM/PO working for TDF. Such PO job is not to be underestimated though – it needs experience and skills.

That would be … unwise IMHO. It is naive to assume that the strategic goals of TDF and LibreOffice always align. While e.g. LibreOffice and TDF share project goals on design and user experience – namely: growing more contributors and spreading the knowledge about how open source productivity works, this is much less so the case on LibreOffice the product: in UI/UX, TDF interests are very specific, e.g. accessibility.

So while growing a strong UI/UX LibreOffice community is a shared goal, on the product side, TDF can IMHO serve LibreOffice better in areas beyond UI/UX e.g. Research and Development like what Simon proposes – doing things that have never been done before.

Best,

Bjoern

You may have your own ideas on what TDF’s interests are, but I was just describing the current reality of how the design team acts as a project manager for new features. The features are the shared goal and we only need a “mini-community” for each one, however opportunistically or purposefully that ends up happening.

After others have answered for me, trying to imagine what my aim was when I called ESC (a very difficult task, and in fact they both went off topic), I will try to answer Miklos (and indirectly all developers).

I read almost every minute of ESC meetings, so I am aware of its activities, and its goals. And I am not so clueless as to think I can ask the developers what to do. At the same time, however, I think the developers could contribute much more than they do to developing ideas for the evolution of LibreOffice. Of course, without this then becoming a constraint on their work, whether in the case of volunteers or employees of companies in the ecosystem.

Each of us has a different relationship with LibreOffice. Users themselves have different ways of using it, and thus of relating to it, depending on their level of competence and familiarity with the technology. Then there are the users who are also supporters of open source software, who combine their relationship with LibreOffice with their choice, which in some cases is philosophical/political and in others simply technical.

The closer we get to the core of the project, the stronger the motivations become with respect to the relationship with the product. For me, LibreOffice has been a life and professional choice, and this - unfortunately - makes my judgement weaker than that of the users, and especially the advanced users, even though I do everything I can to try to abstract myself from my relationship with the project.
Users, however, have a big problem. With a few exceptions, in fact, they make their demands as if LibreOffice were a mouldable material like clay, when it is not. On the contrary, the layers of technology - which in some cases date back to the early years of the project - are often a rigid constraint on development.

Developers, on the other hand, know LibreOffice from the inside, but in some cases do not know it as well as users because it is not on their list of daily tools (with exceptions). Of course, this does not mean that they do not know it, but that they have a different, and important, point of view (because it is based on development experience).

I believe that collaboration between all the different points of view and different relationships with LibreOffice can give rise to interesting ideas about the future of software, combining the sometimes impossible demands of users with the possible reality of developers. How can this be achieved? Certainly not with a weekly meeting, and perhaps not even monthly.

I have always been fascinated by the fact that open source software developers devote one week a year to their own personal project (I hope you still do). What if we did something similar? A focused brainstorming session, two hours twice a year. Just an idea, but we don’t have to come up with a solution today.

The important thing is to agree that it is important to discuss the future of LibreOffice.

2 Likes

As a trustee who is a user and a QA contributor, I also feel that there is some level of “silo’ing” of such high-level and bird’s-eye-view discussions. They seem to happen occasionally and in different places, sometimes (perhaps usually) they occur spontaneously, with the participants not having even intended for their discussion to get to those lofty places. And - the contents of such sporadic and scattered discussions doesn’t propagate very widely - despite our having an annual confernece which should allow for that. Of course this is my personal and anecdotal impression as a non-officer.

Also, if and when it does - is difficult to tell. For example - last year I pitched the idea that we should embrace the view of LibreOffice as a PDF Editor, and cater to that kind of use. This is an evolutionary suggestion rather a request to fix a particular bug. There was decent attendance of my talk; but I have no idea whether the hundreds of non-attending contributors have gave it any thought, or whether “prevailing opinion” has changed etc. (No need to reply on this matter here, it really is just an example.) Specifically, there was never something like an ESC discussion of this, forming some semi-official opinion or disposition.

Maybe ameliorating that should be a central goal itself… although of course it would come at the price of less frequent user-facing improvements for a long while as this is worked on.

I would attend something like that, for sure. OTOH, if many people attend and participate, that becomes unworkable, because nobody would get enough time, and it’s difficult to interact closely with too many people.

1 Like

Your idea is why I became involved in LibreOffice in 2013, doing micro-sponsoring of PDF import improvements. So you can be sure contributors have given it thought. The evolution in this case does happen with individual reports such as 32249 – Make it easier to edit text in imported PDFs and 49705 – Heuristically determine the alignment for paragraphs/text blocks in imported PDFs In the absence of a sudden influx of cash, the work may be organised in the usual peanuts budget way that I described earlier in this thread.

2 Likes

Hi @italovignoli,

Thank you for the clarification and sorry for making assumptions. I like the general idea(*).

Best,

Bjoern

(*) I have a lot of details in mind already that need to be done right for that to work – but as you say: details are topic for later.