It is possible to want to do something while observing that an approach is, on observation, proving less helpful than the proposer(s) would like to imagine.
1 Like
I certainly hope you are not disparaging Mr. Ventura. He is a legend in his own mind!!
OK so I have taken up the âchallengeâ and drafted up a prototype change request capture tool.
It is available at this link: Prototype ipFire Requirements capture
The spreadsheet allows:
- entry of requirements/change requests,
- users to vote on the priority of each proposal,
- developers to provide feedback.
As a prototype, it is input only. It does not:
- calculate any scores,
- 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 look forward to your feedback 
1 Like
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.
1 Like
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âŚ
1 Like
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.
7 Likes
spot on!
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!
4 Likes
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??
1 Like
@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.
BR,
Bernhard
1 Like
Please add this to the list of Top 5.
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.
1 Like
Providing âbad/incorrectly/unpolished/unpointedâ bug tickets for GUI usability is useful?
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.
9 Likes
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.
And once more: IPFIre isnât a commercial product, but a community driven project.
4 Likes
Why?
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â.
3 Likes
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âŚ
I did not remotely suggest Ferrari was the IPFire model. I used multiple examples to kill your simplism.
Given you are off topic and off beam, Iâll leave it there.
Please keep this on-topic for Usability
-moderator
1 Like
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.
1 Like