include features like sorting alphabetically, by score etc.
include other info such as the proposes ID, date of proposal etc.
A key missing feature is to sort the proposals with highest score at the top. This allows a line to be drawn under (say) the top 5 change requests to be allocated development resources.
I have entered my list of change requests , but I am reasonably confident other users will have spotted other changes and improvements they would like to see done.
Access to the spreadsheet is open to anyone with the above link. This can only be acceptable for a prototype. I have and will keep backups so if anyone goes rogue with the contents, I can restore with a backup.
I won’t get to deep in to this discussion but I will say that I consider a “voting” procedure a rather dangerous path if allowed to be to much of an influence on the developers. It can be a prioritization guide, but hardly anything else.
How do you get more opinions, without polls, @sec-con?
Also… devs could read the request but never has been implied (IMVHO) that must comply because the community demands.
Hoever… probably developers will keep updating and fixing Ipfire neverthless, but adopter are a “nice thing” for several reasons…
I followed the discussion from the beginning till now.
From my point of view and this is from a greater distance than most of the participants we have a lot oft words and not a real outcome.
It has for me the impression of a dispute about nothing.
I may be wrong.
I do not want to harm any of the participants of the dispute.
I plea for more focus on subjects which can be solved and action being taken.
For a small company like ipfire we need no bulky concepts.
Sorry, if I appear as a party breaker.
From my point of view there were lots of complaints about the WebGUI that are broken and need to be fixed. And there are lots of words about how to fix “things”. Lots of interesting information about process improvement. But little actual solutions. I am one that believes talk is cheap. Including my words here - ironic, eh?
To me, with few resources (people/volunteers, donated time, donated money) that is a very difficult. So I wanted to see if words could be put into actions.
But this is becoming a big endeavor. The goal was not to boil the ocean (I love cliches!) but just to fix a few issues related to usability.
My focus is exactly what it said in post #45. List a few WebGUI broken items.
Again, spot on!
Let’s just fix a few WebGUI items that are bothering a few people and move on!
One key question that remains unanswered is how are user requirements collected, managed and implemented by the ipFire project?
The latest website refresh includes the statement:
18 months ago I submitted this post Minor WUI Improvements : Pakfire
I tried the simplest option of posting a user requirement on this forum without success. In light of that experience (failure) I have proposed and taken up the challenge of demonstrating a simple means of gathering, polling and prioritizing user requirements, but it seems this has been rejected by those who have posted replies.
It is notable that those objectors have not proposed an alternative method of gathering user requirements beyond a suggestion of using Bugzilla. It would appear that every criticism of my proposal is equally applicable to Bugzilla, if not more so. A good bug reporting tool, but not designed for user requirements.
To use the most recent example:
This raises a number of questions:
Are the developers aware of deficiencies with the WUI, especially if they don’t use the WUI?
Where is the list of all those Web-UI items identified by users (not just me) that need to be fixed?
How does anyone know how many users are bothered by these items?
Are the developers planning to fix the items, they may know about?
All simple questions that should have answers that I, as a user, should be able to find. Although this thread is focused on the WUI, user requirements have no boundary and could extend into the core of ipFire.
So, what is the answer???
What is there to support the claim that “users and developers collaborate”?
What should be in-place to make that claim true??
@dazz:
Most communication about errors or deficiencies happens in this forum.
Both ‘normal’ users and experienced users/devs can take part in this conversation.
A second channel is the devel mailing list and bugzilla. Usually the way you can reach core developers more directly.
The group of moderators of the community usually try to handle minor problems directly or forward the issue to the dev list.
This process requests reproducible descriptions of the possible errors.
Concerning this thread this means a list of problems, as @jon suggested.
Being an experienced user, I use the WUI nevertheless. But having some knowledege about networking, OSs, IPFire I use it ( mostly ) without error. Error handling is a wide area, so you cannot implement it complete. But notifications by users can show up deficiencies, that can be handled.
I cannot answer your key question. One for the core developers would need to respond.
The people that posted a response were volunteers and just trying to help. And I am not sure they have the tools to fix Pakfire, re-compile the code and post a fix. Most of us that respond are part-time volunteers.
Concerning priorities relating to bugs
Bugs go into bugzilla. And there are Severity items for a new bug.
After the process begins it is assigned an Importance. Both of these items help set the priority.
I think there is a misunderstanding here of what that statement means: The IPFire project is entertaining an open dialog about the things its does, including management of the project, development, etc.
It does not mean that anyone can simply put things on the TODO list of developers as they like. People may suggest things, but there is no guarantee that a suggestion will be realised - especially not on development time of others.
Yes, we are very much aware.
We track all sorts of TODO items on our bug tracker.
Yes, if something is difficult to use, or easy to misunderstand that is what I would consider a bug of the software. However, do not take this as an invitation to open tickets for really small things because those will simply just be closed.
Although I care about usability, there are lots of other things that come first.
So the statement “community driven” is formally uncorrect. It’s developer driven. Not questioning the choice, simply suggesting to remove that statement.
I think that there are no nuancese here… if the community push is followed only when it’s liked by the development team… it’s not community driven.
And this is the tombstone to any suggestions from users. Thanks for stating out clearly.
Remember than as in cars… the successul one is not the best one.
But most adopted.
As OSes for computers, currently the succesful one has copyright base in Redmond.
My statement about CLI ‘crawling’ tries to describe the problem of finding issues in the WUI.
Users/devs with a certain level of ability to read/write/correct the source code driving the IPFire system tend to use CLI for deeper log analysis. Therefore they seldomly see problems in usability.
It is the part of IPFire users, which use mainly/only the WUI for configuration and analsysis, to report those cases. Just my opinion.
I think it isn’t a problem WUI vs CLI. But with some expereince and knowedge you tend to make less misstakes in usage. So possible leaks in error handling are not presented to these users.
Therefore it is urgently necessary that less experienced users report those problems and try to give the information demanded by ‘experts’, which want to help.
Further it is true, IMO, that main devs aren’t experts in building a ‘smart’ user interface. For this part all users with expertise in this field are invited to support our team.
To continue your car analogy, by your criterion you say Ferrari and MAN are unsuccessful companies, because they do not sell the most cars/trucks.
Stellantis is the most profitable car company but Toyota sells more cars. Which has more “success”? My preferred car comes from neither so which meets my needs? Are any of those brands “community driven” by the way? Is Apple? Cisco? I must have missed it on their web site. I think that I am far more likely to influence IPFire through Bugzilla than any of those by any means.
Your definition is tautologous, and pretty useless, which goes to your fit of pique over what constitutes “community driven”.
You picked Ferrari. Challenge accepted.
Ferrari, as performance standpoint, is massively price inefficient, but does not have any wish of being diffuse, or need of funding.
Which is the project asking donations quite regularly? Like 12 times at year at least?.
For gaining traction, adopter, founding, probably deliver something that is interesting for possible customers might be a way.
Is this project the Ferrari of firewall distro? Please…
Communicating directly with the devs does not provide visibility of proposed user requirements to the user community. There is no equivalent to bugzilla for gathering/voting/prioritising user requirements.
I posted a notification on this forum 18 months ago that hasn’t been handled, and there is nothing in-place to handle it. That is my point.
It may not seem like it, but I am also a volunteer trying to help. I also don’t have the tools or skills to post a fix.
I am aware of bugzilla, but until this thread I don’t think I knew it was used by ipFire. I can see that the list includes Usability, but a new feature request is not a bug. Adding “usability” in a list does not make bugzilla suitable for gathering user requirements. The Bug Workflow is exactly what I would expect to fix bugs, but it is not applicable to feature requests. For example, it does not include a user voting system for feature requests. Some sort of voting is not required for bugs, but definitely is for feature requests.
No one, including me, has suggested users controlling the devs TODO list. Just the opposite. As discussed in posts above, there are many things that need to be done that are practically invisible to users. I am proposing a simple structured system for gathering user requirements from users, quantifying support for those requirements by allowing all users to vote (user prioritisation). That will tell devs what users really want. It will allow devs to apply scarce resources efficiently to deliver a product that users want.
None of what I am proposing is my invention. It is just good practice.
Sometimes the smallest of things are the most annoying to users. Just rejecting things because they are too small to fix is not a good approach.
The ipFire website identifies security as the No.1 priority, followed by usability. If ipFire isn’t secure and isn’t usable, then the project would be in serious trouble. I do understand there are a lot of things that need to be done to achieve security and usability.
I absolutely agree with @pike_it. If the developers don’t deliver what the users want, then the users will go away and use something else. They won’t complain or post anything on the forum. They just won’t be there.
Remember the Beta-Max verses VHS war. The inferior product won.
Using this comment as a Segway into traffic log analysis. Every good advisor on firewall security recommends that users routinely monitor traffic logs for suspicious activity. I suspect that most users don’t look at traffic logs because most users would not be able to identify suspicious activity.
I hypothesize that most users would vote highly for a new feature that analysed traffic logs and provided a simple (usable) traffic light grading of suspicion. Such a feature would benefit many, if not most, users. It would add a new capability to ipFire that would improve security and usability.
I learned on this thread that ipFire 3.x will include more than just 4 zones. As a user I do use all 4 zones, but I have no need for more than 4 zones. I hypothesize that few users will use or benefit from this new feature. Increasing the number of zones will expand an existing capability with little impact on security or usability.
Community-led development would focus on meeting the needs of users, not just doing what the devs want. For the examples above, I am sure the community would vote to place much greater priority on a traffic log analysis tool than increasing the number of zones.
I may be completely wrong about what users want, but I have no way of knowing that. The same applies to the devs. There is no system to identify and prioritize user requirements. No one knows what ipFire users want. Not me, not the devs.
You can be sure that Ferrari and MAN know exactly what their users want. I directed a project to buy a fleet of MAN trucks and I can assure you that they definitely listen to their customers. They are customer (community) lead. Usability is a high priority. They know that failure to meet customer needs would be fatal for their product.
And that is a problem in itself. Your view and your influence may be completely out of step with the user community. No individual user should have the influence you claim. Not you, not me. Your statement is exactly why Bugzilla is not suitable for gathering and prioritising user requirements. It is not designed for it, and should not be used for it.
My old Professor used to say “it ain’t true if it ain’t measured”. Without a system to gather and prioritize user requirements, ipFire cannot claim collaborative development. Usability is second priority to security, but long standing deficiencies remain in the WUI. Perhaps they are too small to fix. If ipFire does not prioritise user requirements for a secure and usable product, users will go elsewhere.
dazz, you invented propositions I did not make, and also showed no apparent comprehension of bugzilla in use.
I plan not to post further on this thread mainly so you can no longer use my words to fly off in random directions of your choosing. I am not finding your comments useful or enlightening.
Examples:
Rightio.
Oh… It seems the visions are many and varied.
The first two sentences of your final paragraph are essentially unrelated. You might not understand that.
A moderator has already asked to stick to the topic. Having responded to both of you and pike_it, I’ll leave it to avoid risk on my part.
You will also see that on the first page, there is a section that explains where NOT to report those things. Simply, because Discourse is not a bug tracker. There are many posts here, they cannot be referenced by ID and sometimes it is even very hard to find something in the evening that I had read the same morning.
Why do we have these processes? Because it happens that people simply dump comments, sometimes changed scripts and tell us: Here, have it. That is not good enough for the development process of this project. First and foremost we prioritise security and with that comes quality of changes and accountability.
The development process that we are using has been tested over many years and is very similar to many other open source projects. For example the Linux kernel itself. And it works.
GitHub for example has been promoting this “dumping” of changes - they call it a pull request - and that process is one of the many other ways to do things which don’t work for us.
If something is unclear about things, there is one place where to get in touch with the development team:
That is sadly incorrect. You might not have done that, but we do get emails from people who feel free to do so.
This project isn’t a democracy. There are democratic elements to how we make decisions, but it simply isn’t possible for us to make decisions based on majorities. And the reason for that is that we have a huge code base that people would need to know to make a decision. That is not the case, and so we cannot allow people to make decisions out of the blue. We would end of having votes for unicorns and flying cars, just because people would want it - not knowing much about what it actually takes to realise things.
We have tried approaches like crowdfunding in the past which is for example a way where people vote with money. That was however a complete disaster because it was often hard to understand for the funders that simple features require a lot of funding, deeming the process failed from the very start.
In the end, IPFire is of course open source. If the way we are doing things here is not satisfactory, everyone is of course free to fork this project and try their own luck.
Nobody rejected things. In your case, probably nobody else really cared as much as you did.
There is the phrase of scratching your own itch which is the reason why so many open source projects came into existence.
If you want to have a product customised for you (anything really, but let’s maybe say a suit) then you will have to pay someone to do it for you, or you will have to do it yourself. Tailors generally don’t work without being paid. That is also true for myself. Not because I am greedy for money (doing open source is not a good way to become rich), but because I need to fill my fridge and pay my rent, too. I cannot simply sit around all day and develop the things that I want, or somebody else wants. That would be great if I could do that, and our entire donation program is there so that developers can have that freedom, but sadly it is not funding a lot of development work at all.
So, especially when it comes to usability things (replacing icons, renaming buttons), you don’t need a developer. That is a trivial task that can be done by others. And that is what open source projects live from: contribution from others. When I use that word, I explicitly do not mean financial contribution.
Another reason why sometimes you will get little to no reaction on here is because of a proposal not being made the first time. Does IPFire have the best web UI that has ever been? No. Can we make lots of improvements? Yes.
This is not news to us. So don’t expect people to be absolutely excited about some idea that has been discussed many times at length. Trust me, we are working on that.
Why would we only do what we want? Obviously this project exists to be used. By the users.
I am having loads of conversations with people about this. I am sure that I have a pretty good idea which ones are the most pressing items that we need to work on, and which are not. Are those fully representative? No, but they don’t have to be.
I once again disagree with you here. Especially because you are using a car analogy where we have a famous quote from Henry Ford which goes a bit like: If I would have asked people what they need they would have said faster horses.
In the history of IPFire, we have experienced similar many times. Just because something looks like an obviously logical solution doesn’t mean it’s the right way to go forward.
I suppose you will have to have trust in Henry Ford and us as developers that we know which is best. And you will have to trust that we don’t pull any decisions out of thin air, but actually listen and gather as much evidence and data as possible.
Yes, that is okay. IPFire is not a firewall that will make everyone in the world happy. It is designed for a special group of people by a special group of people. And it is far from perfect.
But that is the good thing about the open source world, or even with so many commercial products available: There are alternatives. If you don’t like one, use something else.
Have a try at Cisco (I heard they are selling lots of firewalls) and try to have this discussion with them. You won’t get very far at all. Here, we do listen to you. We understood what you have to say, and believe me, at some point this will influence something that we do.
We cannot however keep having discussions about small things like this for forever. There are so many people that use IPFire and a large silent group is very happy with IPFire is and what it does.
For those who are not happy, there are ways how to influence this project and give their input. There is no guarantee it will be heard, and there is no guarantee it will be realised; although we try as hard as we can.
At the end of the day, we will have to protect the most scarce resource this project has: Time. People’s time.
Hence you might disagree with our development process, but it has indeed been optimised for this one goal. Without that, we don’t need to talk about any next feature, because nobody will have the time to make any meaningful changes to the distribution.
So, I hope that I could answer your questions and I strongly believe that we actually are on the same page. We both want the same: That this project is becoming even more successful than it is now. We might disagree about the how, which is why I am asking you to follow the path that the project has chosen. We have great people here, we have great tools and we have great goals. We need to work together to achieve them though.
) without error. Error handling is a wide area, so you cannot implement it complete. But notifications by users can show up deficiencies, that can be handled.