first - thanks for documenting this and writing it up.

interesting. zero activity on this... nothing to say from anyone?

This is good for an About Us or Philosophy section on a website, but as far as releases and work goes, it doesn't even scratch the surface of what is needed for a roadmap.

In T6768#112939, @raster wrote:

first - thanks for documenting this and writing it up.

interesting. zero activity on this... nothing to say from anyone?

Maybe most people want a roadmap, but they don't feel the need to participate to it?
or they might propose changes to it later?

Here's what I want :)

• elementary : the possibility to make your own widgets easily and possibly share them.
• edc/themes : change edc and see the changes in real time, grammar/rules for edc/themes.
• engine : more opengl/vulkan api support, opengl win engine.
• enlightenment : a library to make your own wm, more touchscreen/tablet/phone support.
• less bugs :)

In T6768#113249, @stephenmhouston wrote:

This is good for an About Us or Philosophy section on a website, but as far as releases and work goes, it doesn't even scratch the surface of what is needed for a roadmap.

I think you should write more precisely what you want this roadmap to be.
The first part about project vision is exactly what you said, but the rest is more like goals (and not "about us/philosophy") discussed by raster.
This is an overall project roadmap. Imho, it's not particularly made for releases and work but more for seeing where the project wants to go.
I discussed about a roadmap/ticket for each release in the original ticket T6740.

In T6768#113251, @indefini wrote:

Maybe most people want a roadmap, but they don't feel the need to participate to it?
or they might propose changes to it later?

This is exactly how I feel about the roadmap :)

In T6768#113251, @indefini wrote:

In T6768#112939, @raster wrote:

first - thanks for documenting this and writing it up.

interesting. zero activity on this... nothing to say from anyone?

Maybe most people want a roadmap, but they don't feel the need to participate to it?
or they might propose changes to it later?

Here's what I want :)

• elementary : the possibility to make your own widgets easily and possibly share them.
• edc/themes : change edc and see the changes in real time, grammar/rules for edc/themes.
• engine : more opengl/vulkan api support, opengl win engine.
• enlightenment : a library to make your own wm, more touchscreen/tablet/phone support.
• less bugs :)

In T6768#113249, @stephenmhouston wrote:

This is good for an About Us or Philosophy section on a website, but as far as releases and work goes, it doesn't even scratch the surface of what is needed for a roadmap.

I think you should write more precisely what you want this roadmap to be.
The first part about project vision is exactly what you said, but the rest is more like goals (and not "about us/philosophy") discussed by raster.
This is an overall project roadmap. Imho, it's not particularly made for releases and work but more for seeing where the project wants to go.
I discussed about a roadmap/ticket for each release in the original ticket T6740.

Nothing in any of this is remotely a roadmap at all. "Project Goals" fine. Roadmap no. And it doesn't help in the slightest stir up interest, get people on board, better structure the project, provide expectations, create reasonable timeframes, provide a synopsis of what people should help with, or improve communication and decision making. It much more feels like notes taken by a teacher of students brainstorming for the class project, when in reality, the teacher has already decided what the project will be.

At any rate. I appreciate the work you are doing -- and I know you would like to do more as many would -- but that you are struggling to get people to agree that what's failing the project is the continued unstructured philosophy, and if this is the best we can do with structure, then clearly it isn't good enough.

Anyhow, your list of what you want is good.
What I want:
A real roadmap (Along with a lot more formal structure in place).

In T6768#113562, @stephenmhouston wrote:

Nothing in any of this is remotely a roadmap at all. "Project Goals" fine. Roadmap no.

This ticket does not really describe a roadmap. Maybe I should change the title but, it says that it is for deciding what it is in the roadmap. What I wrote is just a draft from raster's email, because you have to start somewhere.
So I want to ask you if it is possible to write something like a skeleton of what you really want. If you don't, or someone else doesn't, this ticket will stagnate.

And it doesn't help in the slightest stir up interest, get people on board, better structure the project, provide expectations, create reasonable timeframes, provide a synopsis of what people should help with, or improve communication and decision making. It much more feels like notes taken by a teacher of students brainstorming for the class project, when in reality, the teacher has already decided what the project will be.

I think the current text (for the project overall roadmap) can:

• stir up interest and get people on board : because of the goals and the vision.
• provide expectations in the long term
• provice a synopsis of what people should help with in the long term : also it can but it's more like features

It cannot:

• better structure the project
• create reasonable timeframes
• provide expectations in the short term
• provide a synopsis of what people should help with in the short term
• improve communication and decision making.

That's why I proposed to do a roadmap per release in the original ticket. Each release roadmap would and should provide what the project roadmap can't.

At any rate. I appreciate the work you are doing -- and I know you would like to do more as many would -- but that you are struggling to get people to agree that what's failing the project is the continued unstructured philosophy, and if this is the best we can do with structure, then clearly it isn't good enough.

I agree. I think most people are not interested in management and can endure the problems that comes with no structure.
The original ticket has no activity for a month so I will update it soon to say what should be decided or given up etc.

Maybe most people want a roadmap, but they don't feel the need to participate to it? or they might propose changes to it later?

Well after all the noise about needing/wanting a roadmap, it's disappointing to see how little desire there really is when it comes down to participating in the content. Do people just want me to tell them what to do and issue orders? My experience is that that doesn't work well as people will work on what is a priority or is interesting to them when/if they are willing to. What I hoped to gather is some of that information, because otherwise it'll just end up my personal TODO list. :)

But it's also really vague as to what people want a roadmap to say. Should it be general goals and things to work on or more of a schedule? I hoped that this would explore that. The roadmaps I have seen are more of a wishlist/TODO list and they may give a goal like - would like X for version Y. As we had been doing timed releases, I don't think that feature X for version Y is what we want and we should go back to timed releases as soon as it's feasible to do so. So long-term I just see a rodmap as a TODO list of things that would benefit the project, users, developers or development. Thus what I did was try start the conversation with that - a rough TODO list.

Here's what I want :)

I think that's a great start - people putting their desires down and either no one objecting, or some disagreement and then discussion on why and what to do. Perhaps some prioritization at some point. I'm thumbs up except for 2 of your items:

• edc/themes : change edc and see the changes in real time, grammar/rules for edc/themes.

Technically this is what enventor does. It does require you "Save". It could just auto "save" and rebuild after every change (and if there is no error) update. Right now it's manual to save. Or were you more thinking of something that can monitor a set of files you edit in a text editor anywhere and do a rebuild and update a preview so it'd work with any editor?

• enlightenment : a library to make your own wm, more touchscreen/tablet/phone support.

Doing the library is really hard without also basically making policy. Also keeping compatibility. I think we have enough work doing that for EFL. I do totally agree with the touch/tablet support. I did start some work on that with a new vkbd module... It works decently in X. It does some touch support for a regular "Desktop" mode. Indeed proper mobile "fullscreen always" modes would be better still. I'm with you on this bit.

create reasonable timeframes,

That is unlikely to happen. If people spend whatever time they have on things you cannot have a timeframe. Even if people are paid fulltime this just doesn't happen. And it's not E or EFL alone. Look how long "Wayland will be our desktop next release" happened to many projects and it took multiple years instead. Look how long Firefox has been working on moving to rust and their new engine and just never finishing when they hoped. Look how many years "kdbus would be coming soon" and still hasn't. This is just how things go everywhere. You get my point. I don't like to make promises I can't keep, so just having goals and moving in that direction with regular releases of what is in a good state to release at that time is about as good as it gets. This is how the Linux kernel works and it's the largest open source project out there.

It much more feels like notes taken by a teacher of students brainstorming for the class project, when in reality, the teacher has already decided what the project will be.

At this point that's almost insulting. To both @indefini and me. The whole point of this ticket to to have people actively participate, and you basically are not doing so. You have nothing to say about what a roadmap should have for you, nor what tasks are important to you etc.

What I want: A real roadmap

Then describe what you want. I have described above what I have seen described as "roadmaps".

(Along with a lot more formal structure in place).

We have a lot already. Perhaps you just don't like it, but we do have it. Perhaps you could elaborate to make this conversation valuable?

What I wrote is just a draft from raster's email, because you have to start somewhere.

Indeed. Things have to start somewhere. That was the whole point. Start a conversation.

That's why I proposed to do a roadmap per release

And that I think is something down the road after a longer term bigger picture "roadmap" is discussed. And as it would change continually e.g. from release to release, it's a conversation to keep having all the time and I think it's wise like you said already to separate that out as a separate task.

> At any rate. I appreciate the work you are doing -- and I know you would like to do more as many would -- but that you are struggling to get people to agree that what's failing the project is the continued unstructured philosophy, and if this is the best we can do with structure, then clearly it isn't good enough.
I agree. I think most people are not interested in management and can endure the problems that comes with no structure.

Ummm... I'm confused. It sounds like you disagree, but you say you agree... What exactly did you agree with?

In T6768#113585, @raster wrote:

• edc/themes : change edc and see the changes in real time, grammar/rules for edc/themes.

Technically this is what enventor does. It does require you "Save". It could just auto "save" and rebuild after every change (and if there is no error) update. Right now it's manual to save. Or were you more thinking of something that can monitor a set of files you edit in a text editor anywhere and do a rebuild and update a preview so it'd work with any editor?

I want to see the changes in real time without latency. I change some value in the edc text and it instantly updates, or I could click an object and resize it, set its offsets directly in the preview with the mouse and the text would update.
I think it would make the flow easier and faster. Saving and compiling is too slow imho.

• enlightenment : a library to make your own wm, more touchscreen/tablet/phone support.

Doing the library is really hard without also basically making policy. Also keeping compatibility. I think we have enough work doing that for EFL. I do totally agree with the touch/tablet support. I did start some work on that with a new vkbd module... It works decently in X. It does some touch support for a regular "Desktop" mode. Indeed proper mobile "fullscreen always" modes would be better still. I'm with you on this bit.

If it's too much work, it could be low priority. But if you want efl/enlightenment on any device I think it's not a bad idea to separate the common code into a library. The tizen watch wm must be quite different than e desktop, isn't it?

> At any rate. I appreciate the work you are doing -- and I know you would like to do more as many would -- but that you are struggling to get people to agree that what's failing the project is the continued unstructured philosophy, and if this is the best we can do with structure, then clearly it isn't good enough.
I agree. I think most people are not interested in management and can endure the problems that comes with no structure.

Ummm... I'm confused. It sounds like you disagree, but you say you agree... What exactly did you agree with?

I think I agreed with the struggling part. You said it too, it is disappointing to not see much activity on these tickets. Though it is understandable that developers don't want to spend their (free) time on management.
In the end maybe it's ok if just a few people make decisions about this?

In T6768#113586, @indefini wrote:

In T6768#113585, @raster wrote:

• edc/themes : change edc and see the changes in real time, grammar/rules for edc/themes.

Technically this is what enventor does. It does require you "Save". It could just auto "save" and rebuild after every change (and if there is no error) update. Right now it's manual to save. Or were you more thinking of something that can monitor a set of files you edit in a text editor anywhere and do a rebuild and update a preview so it'd work with any editor?

I want to see the changes in real time without latency. I change some value in the edc text and it instantly updates, or I could click an object and resize it, set its offsets directly in the preview with the mouse and the text would update.
I think it would make the flow easier and faster. Saving and compiling is too slow imho.

• enlightenment : a library to make your own wm, more touchscreen/tablet/phone support.

Doing the library is really hard without also basically making policy. Also keeping compatibility. I think we have enough work doing that for EFL. I do totally agree with the touch/tablet support. I did start some work on that with a new vkbd module... It works decently in X. It does some touch support for a regular "Desktop" mode. Indeed proper mobile "fullscreen always" modes would be better still. I'm with you on this bit.

If it's too much work, it could be low priority. But if you want efl/enlightenment on any device I think it's not a bad idea to separate the common code into a library. The tizen watch wm must be quite different than e desktop, isn't it?

> At any rate. I appreciate the work you are doing -- and I know you would like to do more as many would -- but that you are struggling to get people to agree that what's failing the project is the continued unstructured philosophy, and if this is the best we can do with structure, then clearly it isn't good enough.
I agree. I think most people are not interested in management and can endure the problems that comes with no structure.

Ummm... I'm confused. It sounds like you disagree, but you say you agree... What exactly did you agree with?

I think I agreed with the struggling part. You said it too, it is disappointing to not see much activity on these tickets. Though it is understandable that developers don't want to spend their (free) time on management.
In the end maybe it's ok if just a few people make decisions about this?

I think we have plenty of people willing to spend their time on management. That isn't the problem. It seems to me the problem is no one wants to be managed/no one can agree on what should be managed/no one can agree on how it should be managed ... so in the end the plan is lets just make things up as we go - or depend on whatever raster says.

In T6768#113626, @stephenmhouston wrote:

I think I agreed with the struggling part. You said it too, it is disappointing to not see much activity on these tickets. Though it is understandable that developers don't want to spend their (free) time on management.
In the end maybe it's ok if just a few people make decisions about this?

I think we have plenty of people willing to spend their time on management.

Then where are they? why did they not subscribed to this ticket and said "I want to do it, I want to maintain this project roadmap".

That isn't the problem. It seems to me the problem is no one wants to be managed/no one can agree on what should be managed/no one can agree on how it should be managed ... so in the end the plan is lets just make things up as we go - or depend on whatever raster says.

Yes, there is a problem on what should be and how it should be managed. That is why we opened this ticket to discuss about it!
We already identified some parts of the problem, now let's find/work on solutions.
I think you have to realize at one point that you are still in complaining mode. You have to switch to helping mode now.

In T6768#113627, @indefini wrote:

In T6768#113626, @stephenmhouston wrote:

I think I agreed with the struggling part. You said it too, it is disappointing to not see much activity on these tickets. Though it is understandable that developers don't want to spend their (free) time on management.
In the end maybe it's ok if just a few people make decisions about this?

I think we have plenty of people willing to spend their time on management.

Then where are they? why did they not subscribed to this ticket and said "I want to do it, I want to maintain this project roadmap".

That isn't the problem. It seems to me the problem is no one wants to be managed/no one can agree on what should be managed/no one can agree on how it should be managed ... so in the end the plan is lets just make things up as we go - or depend on whatever raster says.

Yes, there is a problem on what should be and how it should be managed. That is why we opened this ticket to discuss about it!
We already identified some parts of the problem, now let's find/work on solutions.
I think you have to realize at one point that you are still in complaining mode. You have to switch to helping mode now.

I'm not complaining here -- The problem is, going back to even reading the original ticket you created -- Time based or released based road maps are not of interest to those responding, including raster. Which is why I said -- people can't agree on what, when, how. We can do this wish list that is this ticket basically is -- and that is fine -- I just don't feel it improves structure or management.

In T6768#113660, @stephenmhouston wrote:

Yes, there is a problem on what should be and how it should be managed. That is why we opened this ticket to discuss about it!
We already identified some parts of the problem, now let's find/work on solutions.
I think you have to realize at one point that you are still in complaining mode. You have to switch to helping mode now.

I'm not complaining here -- The problem is, going back to even reading the original ticket you created -- Time based or released based road maps are not of interest to those responding, including raster. Which is why I said -- people can't agree on what, when, how. We can do this wish list that is this ticket basically is -- and that is fine -- I just don't feel it improves structure or management.

Yes people don't agree and that's normal, not a problem we cannot fix. This is why there is discussion to find a consensus or convince one another. People cannot radically change the way they work or the way they think in an instant.
If you feel this ticket doesn't improve structure, but released based roadmaps do, you can discuss on the original ticket.

Time based or released based road maps are not of interest to those responding, including raster

You have GOT TO BE KIDDING. Let me quote myself above:

so just having goals and moving in that direction with regular releases of what is in a good state to release at that time is about as good as it gets. This is how the Linux kernel works and it's the largest open source project out there.

That is TIME BASED RELEASES. @indefini is 100% right - you are just wanting to complain and not bother with help because you don't even bother to read what does not fit your narrative. At least have the decency to read what I have written before pointing fingers at me claiming something that is utterly untrue. If there is one way to piss me off it is to accuse me of things that are absolutely untrue and OBVIOUSLY untrue. It's the 2nd insult you've managed in just this ticket. I'm beginning to think the problems in this project are people like you creating trouble where there is none. Yes. I'm calling you out on this.

I just don't feel it improves structure or management.

And exactly as @indefini said - you are totally unwilling to work on it but just complain. I asked 2 key questions above you didn't bother to respond to which would move things forward and just went back into complaining.

> What I want: A real roadmap
Then describe what you want. I have described above what I have seen described as "roadmaps".

and

> (Along with a lot more formal structure in place).
We have a lot already. Perhaps you just don't like it, but we do have it. Perhaps you could elaborate to make this conversation valuable?

@stephenmhouston: Stop complaining. Stop telling lies that fit your narrative. Be part of the solution, not be the problem.

I want to see the changes in real time without latency. I change some value in the edc text and it instantly updates, or I could click an object and resize it, set its offsets directly in the preview with the mouse and the text would update.
I think it would make the flow easier and faster. Saving and compiling is too slow imho.

Aaaah ok. The real problem is eet was designed for write-once, read many times, so writing is slow as it re-writes and re-compresses the whole file. if it only wrote/re-compressed the bits that changed it might be much faster. edje_cc doesn't have a "rewrite" mode either. just a "write it all out". To accomplish this, this end of things would need to be tackled. It's both in eet and edje_cc and it might be tricky and require compromises.

If it's too much work, it could be low priority. But if you want efl/enlightenment on any device I think it's not a bad idea to separate the common code into a library. The tizen watch wm must be quite different than e desktop, isn't it?

They forked and heavily modified to "reduce size" and so they only want to work on what is relevant for tizen and not anything else. a "WM lib" would be large and have to address lots of uses and thus would be of little to no interest to that kind of path. Keeping compatibility is going to be a nightmare. I think it'd be in the end a waste of time as the only users would end up being us. That at least is my conclusion. It'd be a mountain of work, a mountain of ongoing work, and for just E ... :) I think EFL has about the right split of splitting stuff out of the WM into something generically useful. :)

I think I agreed with the struggling part

Well I don't think there is a struggle to get agreement in lots of areas. I think it's a struggle to get people to stop banging whatever drum they have and actually be helpful at all. you already pointed out. There is a lot of "complain" without any movement to "then what do we do?". At least you and me are having a productive discussion that actually agrees on various things already and is exploring more.

In the end maybe it's ok if just a few people make decisions about this?

Well that is what has happened in the past and the problem is now: "I don't like your decisions". A few decided on timed releases - INCLUDING me. That fell apart a bit hoping to get eo/interfaces done for a specific release. That's kind of been ongoing as that elephant doesn't move along fast. I and some others also decided on the model that trusted developers get commit access and review is done afterwards maybe with changes or reverts on the odd occasion the commit is an issue vs review for untrusted devs. I like that model as it speeds things up for core devs who do get things 99% right and once in a while mess up, yet keeps barriers in place for those not yet trusted to get things right. Review doesn't fix this. I have reverted or fixed patches that have gone through review as they broke things badly and I'm not sure the error rate is any lower there, so I think on balance we have something fast, efficient, yet with enough controls in place. I like fast and efficient. I dislike wasting time. Review takes up a lot of time and when the input hours vs reward value is not there, I like to skip it. Look at how many patches just end up in bikeshedding and end up going nowhere. I think this is devil you know vs devil you don't and neither path is better or really worse.

Reality is any decisions are not going to be universally pleasing to everyone. It is always going to be that way in any group large enough. I don't think the goal should be to please everyone. The goal should be to make things work as best as possible for the best "price" in time/effort etc.. There is always room for discussion on that and tweaking where needed. It doesn't mean that just because things can change that such changes would be better, it may just be replacing the devil you know with the devil you don't. But discussing at least brings out the argument.

I think that's probably far enough down that path without concrete information.

In T6768#113676, @raster wrote:

Time based or released based road maps are not of interest to those responding, including raster

You have GOT TO BE KIDDING. Let me quote myself above:

so just having goals and moving in that direction with regular releases of what is in a good state to release at that time is about as good as it gets. This is how the Linux kernel works and it's the largest open source project out there.

That is TIME BASED RELEASES. @indefini is 100% right - you are just wanting to complain and not bother with help because you don't even bother to read what does not fit your narrative. At least have the decency to read what I have written before pointing fingers at me claiming something that is utterly untrue. If there is one way to piss me off it is to accuse me of things that are absolutely untrue and OBVIOUSLY untrue. It's the 2nd insult you've managed in just this ticket. I'm beginning to think the problems in this project are people like you creating trouble where there is none. Yes. I'm calling you out on this.

I think he meant release roadmaps (time based or released based roadmaps) compared to this project roadmap that this ticket is about. I think he might be more interested about those than this project one.
And he says that you don't seem interested in release roadmaps because you wrote in the original ticket that you wouldn't gor for a per release roadmap.
I don't think he wants to tell lies :) this is just some misunderstanding :)

In T6768#113677, @raster wrote:

In the end maybe it's ok if just a few people make decisions about this?

Well that is what has happened in the past and the problem is now: "I don't like your decisions". A few decided on timed releases - INCLUDING me. That fell apart a bit hoping to get eo/interfaces done for a specific release. That's kind of been ongoing as that elephant doesn't move along fast. I and some others also decided on the model that trusted developers get commit access and review is done afterwards maybe with changes or reverts on the odd occasion the commit is an issue vs review for untrusted devs. I like that model as it speeds things up for core devs who do get things 99% right and once in a while mess up, yet keeps barriers in place for those not yet trusted to get things right. Review doesn't fix this. I have reverted or fixed patches that have gone through review as they broke things badly and I'm not sure the error rate is any lower there, so I think on balance we have something fast, efficient, yet with enough controls in place. I like fast and efficient. I dislike wasting time. Review takes up a lot of time and when the input hours vs reward value is not there, I like to skip it. Look at how many patches just end up in bikeshedding and end up going nowhere. I think this is devil you know vs devil you don't and neither path is better or really worse.

I think we already had discussions about have reviews or not.
I wrote in the original ticket comments that we could just encourage reviews if people felt the need for it.
Basically if you are a commiter you have the choice to ask for a review or not.
You would still have the flexibility to move fast and break stuff :)

I think he meant release roadmaps (time based or released based roadmaps) compared to this project roadmap that this ticket is about. I think he might be more interested about those than this project one.

That was part of the same response...

That's why I proposed to do a roadmap per release

And that I think is something down the road after a longer term bigger picture "roadmap" is discussed. And as it would change continually e.g. from release to release, it's a conversation to keep having all the time and I think it's wise like you said already to separate that out as a separate task.

I am obviously interested in both time based releases and roadmaps in general and time based roadmaps are what we were doing - releases on a 12 weeks cycle (approximately) and time based releases are just that. The roadmap is a schedule. That is how all the time based release projects I know work. patch/feature makes it or it doesn't each cycle. Otherwise it's a general roadmap for tasks/things being done or needing to be done and they make it or not for a release.

I think we already had discussions about have reviews or not.

But it keeps being brought up here vaguely. As I said and you say - what we have already for years had is just what you describe. Devs with commit access can commit. They can ask for review too if they are not sure.

In T6768#113679, @indefini wrote:

In T6768#113676, @raster wrote:

Time based or released based road maps are not of interest to those responding, including raster

You have GOT TO BE KIDDING. Let me quote myself above:

so just having goals and moving in that direction with regular releases of what is in a good state to release at that time is about as good as it gets. This is how the Linux kernel works and it's the largest open source project out there.

That is TIME BASED RELEASES. @indefini is 100% right - you are just wanting to complain and not bother with help because you don't even bother to read what does not fit your narrative. At least have the decency to read what I have written before pointing fingers at me claiming something that is utterly untrue. If there is one way to piss me off it is to accuse me of things that are absolutely untrue and OBVIOUSLY untrue. It's the 2nd insult you've managed in just this ticket. I'm beginning to think the problems in this project are people like you creating trouble where there is none. Yes. I'm calling you out on this.

I think he meant release roadmaps (time based or released based roadmaps) compared to this project roadmap that this ticket is about. I think he might be more interested about those than this project one.
And he says that you don't seem interested in release roadmaps because you wrote in the original ticket that you wouldn't gor for a per release roadmap.
I don't think he wants to tell lies :) this is just some misunderstanding :)

Don't let facts get in the way of crazy accusations and insults...