[Gimp-developer] Enhancement request policy
Hi, in the light of current events one problem comes up again: how do we deal with enhancement requests reported in Bugzilla? Currently we count 1'193 open GIMP bugs, of which 607 are enhancement requests. We're drowning in them. In 2015 Jim DeLaHunt pointed out a discrepancy between the website and the documentation, see https://mail.gnome.org/archives/gimp-developer-list/2015-February/msg3.html Unfortunately the topic wasn't discussed, but still persists and is in a current case time consuming and going blue. In the past I already closed bugs as INVALID until they are agreed upon on the mailing list, but it wasn't considered the best solution. Actually we put the bug on hold, but Bugzilla has no bug state for this. How about this: 1. On enhancement requests we check for Bugzilla duplicates and former mailing list discussions. On duplicates and formerly disagreed requests we close the bug with a suitable reason as DUPLICATE or WONTFIX. 2. If the request is not a duplicate we answer with an friendly stock answer and ask to bring the topic to the developer mailing list. If it's a pure GUI topic, then to the gimp-gui mailing list. Until the topic is discussed with a clear result, we set the bug into NEEDINFO state. 3. On agreement we set the bug into state NEW, otherwise close it as WONTFIX. If the reporter refuses to post the request to the mailing list, then either we post it there if we think it's useful, otherwise we close it as INVALID. If no further discussion is ongoing we close the bugs after an agreed period of time, e.g. 3 weeks since reporting. The goals are getting useful feedback, while keeping the bug base small. It would be nice if we found a final solution now and made it clear at the website and in the documentation. Greetings Sven ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Enhancement request policy
Hi, no reply yet. I asked the devs to discuss it at the LGM, but so far I don't see anything in the (intermediate state of) the meeting minutes. Was it discussed and to which result? Greetings Sven ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Enhancement request policy
Hello, I don't believe this was in the items of the GIMP meeting at LGM. This said, I arrived slightly late, and it was very hard to keep up on everything which was being said because the table was huge and the room very noisy. So maybe I missed this discussion. Anyway I'll give my opinion here on the topic: I don't think this is any kind of problem to let feature requests live in the bugzilla. We know what a feature request is, we know that it is not prioritary compared to bugs. For me that is not a problem to have dozens, if not hundreds, of these staying in the bugtracker. Numbers are not a problem for me. We have many feature requests? So what? :-) As soon as we are sure that a request is not going in the same direction as GIMP, we can close it as INVALID. If a request is implemented, close as FIXED. And if we are still not sure of a feature or if we may implement it later, then it is ok to keep the report around for the time being, in my opinion. On the other hand, mailing lists are time-fleeting. A topic there disappears. So I think they are awesome to have a discussion about a feature. If some report gets too big and everyone disagrees on a feature, it may be good to continue discussing on the mailing list (otherwise Mitch will go crazy!). But it is good also that the original reports stays put. And when we come to an agreement on the mailing list, we can report it to the bug report. This is my opinion on this topic. Jehan P.S.: by the way, didn't we already discuss it months/years ago? On Wed, Apr 20, 2016 at 6:07 AM, Sven Claussner wrote: > > Hi, > > no reply yet. > I asked the devs to discuss it at the LGM, but so far > I don't see anything in the (intermediate state of) > the meeting minutes. > Was it discussed and to which result? > > > Greetings > > Sven > > > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list -- ZeMarmot open animation film http://film.zemarmot.net Patreon: https://patreon.com/zemarmot ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Enhancement request policy
My point of view is: enchancements should be discussed on the forum, not in a bugtracker. Here is what DispCalGUI has: https://hub.displaycal.net/forums/ Mailing list is not exceptionally convenient for many people (myself included. I just mailed topic starter instead of mailing to the list thinking that replying to mail will get it done. I now pressed "reply to all") but may be still better than discussing enchancements in bugtracker. Imgaine that every user wants something new. Because of number of users being magnitudes larger than number of developers (who are not paid) and those willing to contribute the project is guaranteed to drown in requests. Bugtracker is for developers and they should pick doable tasks from forum themselves. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Enhancement request policy
Am Samstag, 23. April 2016, 11:40:26 schrieb Euri Pinhollow: [...] > Bugtracker is for developers and they should pick doable tasks from > forum themselves. Most developers are too busy doing developing to read any forums. Communication is either actively pushed their way (i.e., via mail) or ignored. That's at least what I learned over the years. Tobias signature.asc Description: This is a digitally signed message part. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Enhancement request policy
The great advantage of the bug-tracker is that it allows requests to be handled in a structured way. It is easy to find specific types of enhancement requests in the bug-tracker and examine the priority they have been given and the discussion that followed them. Getting this information from a forum is usually much more difficult. It is quite reasonable to bring up enhancement ideas in a forum and discuss them there until they are reasonably specific and coherent, but once that has happened it is helpful to have an enhancement request created in the bug-tracker. If the developers don't like them, they can always be classified as WONTFIX or NOTABUG. On Sat, Apr 23, 2016 at 1:40 AM, Euri Pinhollow wrote: > My point of view is: enchancements should be discussed on the forum, > not in a bugtracker. Here is what DispCalGUI has: > https://hub.displaycal.net/forums/ > > Mailing list is not exceptionally convenient for many people (myself > included. I just mailed topic starter instead of mailing to the list > thinking that replying to mail will get it done. I now pressed "reply > to all") but may be still better than discussing enchancements in > bugtracker. > > Imgaine that every user wants something new. Because of number of > users being magnitudes larger than number of developers (who are not > paid) and those willing to contribute the project is guaranteed to > drown in requests. > > Bugtracker is for developers and they should pick doable tasks from > forum themselves. > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > List membership: > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list > ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Enhancement request policy
My experience is that GIMP developers don't care what any user would like to have. The general response is "we have previously decided that we want to do it like this and we aren't interested in how the end user might find something useful". This is in stark contrast to most of the other open source projects that I work on that gladly take constructive input. On 23 April 2016 at 09:51, Bill Skaggs wrote: > The great advantage of the bug-tracker is that it allows requests to be > handled in a structured way. It is easy to find specific types of > enhancement requests in the bug-tracker and examine the priority they have > been given and the discussion that followed them. Getting this information > from a forum is usually much more difficult. > > It is quite reasonable to bring up enhancement ideas in a forum and discuss > them there until they are reasonably specific and coherent, but once that > has happened it is helpful to have an enhancement request created in the > bug-tracker. If the developers don't like them, they can always be > classified as WONTFIX or NOTABUG. > > > > On Sat, Apr 23, 2016 at 1:40 AM, Euri Pinhollow wrote: > >> My point of view is: enchancements should be discussed on the forum, >> not in a bugtracker. Here is what DispCalGUI has: >> https://hub.displaycal.net/forums/ >> >> Mailing list is not exceptionally convenient for many people (myself >> included. I just mailed topic starter instead of mailing to the list >> thinking that replying to mail will get it done. I now pressed "reply >> to all") but may be still better than discussing enchancements in >> bugtracker. >> >> Imgaine that every user wants something new. Because of number of >> users being magnitudes larger than number of developers (who are not >> paid) and those willing to contribute the project is guaranteed to >> drown in requests. >> >> Bugtracker is for developers and they should pick doable tasks from >> forum themselves. >> ___ >> gimp-developer-list mailing list >> List address:gimp-developer-list@gnome.org >> List membership: >> https://mail.gnome.org/mailman/listinfo/gimp-developer-list >> List archives: https://mail.gnome.org/archives/gimp-developer-list >> > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Enhancement request policy
* john smith [04-29-16 12:38]: > My experience is that GIMP developers don't care what any user would > like to have. > The general response is "we have previously decided that we want to do > it like this and we aren't interested in how the end user might find > something useful". > This is in stark contrast to most of the other open source projects > that I work on that gladly take constructive input. > > On 23 April 2016 at 09:51, Bill Skaggs wrote: > > The great advantage of the bug-tracker is that it allows requests to be > > handled in a structured way. It is easy to find specific types of > > enhancement requests in the bug-tracker and examine the priority they have > > been given and the discussion that followed them. Getting this information > > from a forum is usually much more difficult. > > > > It is quite reasonable to bring up enhancement ideas in a forum and discuss > > them there until they are reasonably specific and coherent, but once that > > has happened it is helpful to have an enhancement request created in the > > bug-tracker. If the developers don't like them, they can always be > > classified as WONTFIX or NOTABUG. > > > > > > > > On Sat, Apr 23, 2016 at 1:40 AM, Euri Pinhollow wrote: > > > >> My point of view is: enchancements should be discussed on the forum, > >> not in a bugtracker. Here is what DispCalGUI has: > >> https://hub.displaycal.net/forums/ > >> > >> Mailing list is not exceptionally convenient for many people (myself > >> included. I just mailed topic starter instead of mailing to the list > >> thinking that replying to mail will get it done. I now pressed "reply > >> to all") but may be still better than discussing enchancements in > >> bugtracker. > >> > >> Imgaine that every user wants something new. Because of number of > >> users being magnitudes larger than number of developers (who are not > >> paid) and those willing to contribute the project is guaranteed to > >> drown in requests. > >> > >> Bugtracker is for developers and they should pick doable tasks from > >> forum themselves. > >> ___ > >> gimp-developer-list mailing list > >> List address:gimp-developer-list@gnome.org > >> List membership: > >> https://mail.gnome.org/mailman/listinfo/gimp-developer-list > >> List archives: https://mail.gnome.org/archives/gimp-developer-list > >> > > ___ > > gimp-developer-list mailing list > > List address:gimp-developer-list@gnome.org > > List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list > > List archives: https://mail.gnome.org/archives/gimp-developer-list > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list I find the dev's interested, helpful, attentive, and goal oriented. Because one does not agree with the projects goal does not make the dev's uncaring, but exposes ignorance of the goal. Proposals should be aligned to the project goals and enhance efforts to achieve that goal. Should one not agree with the project's goal, he/she should undertake another project with that goal in mind rather than deride those who have a purpose in mind. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://linuxcounter.net ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Enhancement request policy
29 апр. 2016 г. 19:37 пользователь "john smith" написал: > > My experience is that GIMP developers don't care what any user would > like to have. What experience would that be exactly? Alex ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Enhancement request policy
> > My experience is that GIMP developers don't care what any user would > like to have. > Clearly untrue. We have the Unified Transform Tool, hardware acceleration, Mypaint brush engine, and (up to) 64bit colour depth, and linear light blending modes to look forward to in the next release, the freakishly awesome Handle Transform tool, a proper on-canvas warp-tool, and so so many more awesome things that users (including myself) have been asking for, and anxiously awaiting. There are things that I've asked for that didn't get implemented, but the minute I start feeling bad about GIMP, and where it's going, or that one thing I consider a priority over all others, I take a step back and and go use other image editors for a while. I'm usually back to GIMP within a day or so. :) Better yet, if I think my idea is really good, I could go about getting more of the community behind it with mockups and hanging out in the irc channels and asking/answering questions. Sitting silent on the gimp-developer mailing list and only poking my head up to offer up some ill-timed tautological criticism does zero good for anyone, I've found. There are some topics that just go round and round, which is why you will find devs (and the community) going with a previously established answer. Everyone's really sick of arguing about these things, and you can tell right away witch ones they are, because they are in the FAQ on GIMP.org, and you can feel the tension around the question and answer like a thick soup. No one wants that soup, so generally we send it back when someone offers up another helping of the same. :) > The general response is "we have previously decided that we want to do > it like this and we aren't interested in how the end user might find > something useful". > Ah "The End User". One end user's "might find something useful" is another user's horrendous workflow bottleneck. If it was previously decided on, there's likey a good reason for it. Could probably ask what the reasons are for enlightenment. This is in stark contrast to most of the other open source projects > that I work on that gladly take constructive input. > GIMP is a huge program with lots of end users, of which every one has their own priorities, workflow preferences, etc. GIMP also has very few developers, so a set list of priorities matter all the more. Thanks to everyone who works on GIMP. The current batch of new features in trunk are going to make waves in the community. It's a tremendous gift, and should be treated as such. My 2p > On 23 April 2016 at 09:51, Bill Skaggs wrote: > > The great advantage of the bug-tracker is that it allows requests to be > > handled in a structured way. It is easy to find specific types of > > enhancement requests in the bug-tracker and examine the priority they > have > > been given and the discussion that followed them. Getting this > information > > from a forum is usually much more difficult. > > > > It is quite reasonable to bring up enhancement ideas in a forum and > discuss > > them there until they are reasonably specific and coherent, but once that > > has happened it is helpful to have an enhancement request created in the > > bug-tracker. If the developers don't like them, they can always be > > classified as WONTFIX or NOTABUG. > > > > > > > > On Sat, Apr 23, 2016 at 1:40 AM, Euri Pinhollow > wrote: > > > >> My point of view is: enchancements should be discussed on the forum, > >> not in a bugtracker. Here is what DispCalGUI has: > >> https://hub.displaycal.net/forums/ > >> > >> Mailing list is not exceptionally convenient for many people (myself > >> included. I just mailed topic starter instead of mailing to the list > >> thinking that replying to mail will get it done. I now pressed "reply > >> to all") but may be still better than discussing enchancements in > >> bugtracker. > >> > >> Imgaine that every user wants something new. Because of number of > >> users being magnitudes larger than number of developers (who are not > >> paid) and those willing to contribute the project is guaranteed to > >> drown in requests. > >> > >> Bugtracker is for developers and they should pick doable tasks from > >> forum themselves. > >> ___ > >> gimp-developer-list mailing list > >> List address:gimp-developer-list@gnome.org > >> List membership: > >> https://mail.gnome.org/mailman/listinfo/gimp-developer-list > >> List archives: https://mail.gnome.org/archives/gimp-developer-list > >> > > ___ > > gimp-developer-list mailing list > > List address:gimp-developer-list@gnome.org > > List membership: > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > > List archives: https://mail.gnome.org/archives/gimp-developer-list > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > List membership: > https://mail.gnome.o
Re: [Gimp-developer] Enhancement request policy
On 29 April 2016 at 13:52, C R wrote: >> My experience is that GIMP developers don't care what any user would >> like to have. > > > Clearly untrue. We have the Unified Transform Tool, hardware acceleration, > Mypaint brush engine, and (up to) 64bit colour depth, and linear light > blending modes to look forward to in the next release, the freakishly > awesome Handle Transform tool, a proper on-canvas warp-tool, and so so many > more awesome things that users (including myself) have been asking for, and > anxiously awaiting. > > There are things that I've asked for that didn't get implemented, but the > minute I start feeling bad about GIMP, and where it's going, or that one > thing I consider a priority over all others, I take a step back and and go > use other image editors for a while. I'm usually back to GIMP within a day > or so. :) > > Better yet, if I think my idea is really good, I could go about getting more > of the community behind it with mockups and hanging out in the irc channels > and asking/answering questions. Sitting silent on the gimp-developer mailing > list and only poking my head up to offer up some ill-timed tautological > criticism does zero good for anyone, I've found. > Spotted the lurker having a bad day :) > There are some topics that just go round and round, which is why you will > find devs (and the community) going with a previously established answer. > Everyone's really sick of arguing about these things, and you can tell right > away witch ones they are, because they are in the FAQ on GIMP.org, and you > can feel the tension around the question and answer like a thick soup. No > one wants that soup, so generally we send it back when someone offers up > another helping of the same. :) > >> >> The general response is "we have previously decided that we want to do >> it like this and we aren't interested in how the end user might find >> something useful". > > > Ah "The End User". One end user's "might find something useful" is another > user's horrendous workflow bottleneck. If it was previously decided on, > there's likey a good reason for it. Could probably ask what the reasons are > for enlightenment. > You say that noone wants that soup and are sick of arguing it, but surely the logic follows that if the users DIDN'T want it, they wouldn't keep bringing it up. However, they do and the arguments ensue, which highlights my point about devs not being receptive. A good example of this where it is not just one user is the export/save as, which can be followed in the list history. These sorts of clashes can be resolved much more easily by putting configuration options in. Sure it adds an extra test to be covered in your code but you are now catering to both sides. Another historical example is the single window mode and how popular GimpShop was when it came out and how long core devs resisted before implementing it. >> This is in stark contrast to most of the other open source projects >> that I work on that gladly take constructive input. > > > GIMP is a huge program with lots of end users, of which every one has their > own priorities, workflow preferences, etc. > GIMP also has very few developers, so a set list of priorities matter all > the more. There seems to be a more aggressive stance here though on what are priorities and what is just denials. You don't see a response that often saying "thats an interesting proposal for our UI but we are focussing on this core algorithm right now so it will have to go on the back burner". You are more likely to get an argument about the idea and how it doesn't fit with the vision. > > Thanks to everyone who works on GIMP. The current batch of new features in > trunk are going to make waves in the community. It's a tremendous gift, and > should be treated as such. > > My 2p > Having said all this, you make a good point about all the new features and it is much easier to complain than add these features! > >> >> On 23 April 2016 at 09:51, Bill Skaggs wrote: >> > The great advantage of the bug-tracker is that it allows requests to be >> > handled in a structured way. It is easy to find specific types of >> > enhancement requests in the bug-tracker and examine the priority they >> > have >> > been given and the discussion that followed them. Getting this >> > information >> > from a forum is usually much more difficult. >> > >> > It is quite reasonable to bring up enhancement ideas in a forum and >> > discuss >> > them there until they are reasonably specific and coherent, but once >> > that >> > has happened it is helpful to have an enhancement request created in the >> > bug-tracker. If the developers don't like them, they can always be >> > classified as WONTFIX or NOTABUG. >> > >> > >> > >> > On Sat, Apr 23, 2016 at 1:40 AM, Euri Pinhollow >> > wrote: >> > >> >> My point of view is: enchancements should be discussed on the forum, >> >> not in a bugtracker. Here is what DispCalGUI has: >> >> https://hub.displaycal.net/fo
Re: [Gimp-developer] Enhancement request policy
> > > Spotted the lurker having a bad day :) > > All of us play that part sometime. It's important to get over it and move on, and not to send out emails to the group while upset. Being part of the community means being social. Part of being social is not being a lurker. :) > You say that noone wants that soup and are sick of arguing it, but > surely the logic follows that if the users DIDN'T want it, they > wouldn't keep bringing it up. > If it's debated (for example changing the name GIMP), then there is no consensus. If it were obviously the right thing to do it would be in the vision. If it's not, or is counter to the vision, we have to assess if we need to change the vision. So it's still not a matter of users vs devs, it's SOME users vs. one idea, one previous decision. People get cranky when their idea is rejected, which is also why the soup tastes bad after only a short time. Again read the FAQ for other good examples. However, they do and the arguments ensue, which highlights my point > about devs not being receptive. > The devs are "receptive" they just don't comply or agree with every ask. Again, the tautologies are clearly untrue. One idea from one users (even backed by many users) does not constitute "All users" or even "users in general". Each of us would like to think our ideas are great for the GIMP project, but it's not always the case. One users most wanted feature is another's terrible workflow bottleneck. > A good example of this where it is not just one user is the > export/save as, which can be followed in the list history. > Yep, but again, not all users agree with changing it back to the way it used to be. They did put in a work-around where if you forget to export, you can click "take me to the export dialog" link in the warning message, and you're good to go. So that's a decent compromise. > These sorts of clashes can be resolved much more easily by putting > configuration options in. > Sometimes. And also many are actually put in as options, which is why we have things like the hotkey and input editors. > Sure it adds an extra test to be covered in your code but you are now > catering to both sides. > GIMP's development focus is on professional users who use GIMP for graphics/photo work. Bowing to every user request for a work-around makes a cluttered and endless mess of the options, and an increasingly inconsistent UI. It also may involve re-writing large chunks of the interface which may clash with other parts. Another historical example is the single window mode and how popular > GimpShop was when it came out and how long core devs resisted before > implementing it. > But, we have single window mode... so... ? Seems like an example of GIMP devs listening to users, doesn't it? The mission of GIMPShop was to bring a PhotoShop clone interface to GIMP. Note how it's also a dead project at this point. >> This is in stark contrast to most of the other open source projects > >> that I work on that gladly take constructive input. > Constructive input is fine. Ranty emails about how no one listens are not constructive input. Also, just because it's constructive does not mean it's good for the project, and is no guarantee that it will be accepted. People hear "no" and take it personally. But it's not just "no" is it? There's always an explanation behind it. So it's not even a matter of devs not listening. > There seems to be a more aggressive stance here though on what are > priorities and what is just denials. > You don't see a response that often saying "thats an interesting > proposal for our UI but we are focussing on this core algorithm right > now so it will have to go on the back burner". > You are more likely to get an argument about the idea and how it > doesn't fit with the vision. > Users also only see the tip of the iceberg. From the FAQ: "While working on functional specifications, Peter researched how various features are implemented in applications with a partially matching feature set (such as Adobe Photoshop), but the final design was made to help actual users complete their tasks as fast as possible. This is exactly the kind of approach to designing interfaces that we consider to be superior to merely copying user interaction decisions." For your idea, how much UI testing and UX diagrams did you do? Is your idea even the best one? Is it better and faster in most workflows, or just in your workflow? Like most things in life, if you can put together a good mockup, get support from the community, and present a complete solution, it's much more likely to be considered. > Having said all this, you make a good point about all the new features > and it is much easier to complain than add these features! > > My point is that devs DO listen to users. They do a lot more than not, so the answer "no" is not them not listening, it's them rejecting the idea, which has been rejected before for the same reason(s) in the past. As in all things the strength
