Improving Usability?

Yes, action is required.

I can create a ToDo list, but it is likely to be different to a ToDo list created by any other ipFire user. This should be at least a 4 step process:

  1. Someone (any registered ipFire user who can log-on to the ipFire website) proposes a change including benefits. There should be no limits on the quantity, scope or development effort.

  2. All registered users have an opportunity to vote on proposed changes.

  3. The Developers estimate the cost (developer hours) of each proposal.

  4. The Developers plan, schedule allocate resources and then complete the top scoring change proposal.

The Developers will not be able to allocate all resources to changes. Resources will still need to be expended on routine maintenance, admin type work and other essential, but unexciting, work behind the scenes.

Scoring to rank proposals can be a multi-factor combination of:

User Votes
4 - 80% to 100%
3 - 50% to 79%
2 - 20% to 49%
1 - 0% to 19%

Benefits
4 - All users, major improvements for security / usability / functionality (not the same as adding features)
3 - Most users, significant improvements for security / usability / functionality
2 - Some users, some improvements for security / usability / functionality
1 - Outlier users, specific use-case for some change that cannot be reasonably achieved by a work-around.

Priority
4 - Must have
3 - Should have
2 - Could have
1 - Must not have

Resources (Cost)
Measured in Developer hours:
4 - Less than 8 hours (1 day)
3 - Less than 40 hours (1 week)
2 - Less than 160 hours (1 month)
1 - Less than 1000 hours (6 months)

Given the scarcity of resources, this factor may need a weighted score (eg. 2x)

Initial investigation indicates this proposal tracking voting and scoring could be done on a on-line spreadsheet that is part of the Wiki or Community website. Such a spreadsheet would be accessible to every user with a log-in. No single person (including me) should decide what can/can’t be proposed as a change.

It is my experience that user groups exist to improve something, not change it into something it isn’t. ipFire users can expect users to propose changes to make a better firewall and not something else.

All of the above might be just too much for ipFire, so a crawl/walk/run approach would be appropriate. A start could be made with a simplified version which is then scaled as required.

Developer Buy-in
I did a little digging around and it appears that ipFire may have had elements of user-led development in the past.

Monthly Video Conference
I found minutes of monthly on-line meetings here: Monthly Conference Records This is good stuff. I read a random sample of the minutes. As far as I can tell, this is attended by Developers only, but there does not appear to be any restriction on who can attend.

I found a item titled “Community Suggestion” and also “Addon Removals” (8 Jan 2024). So the developers do pay attention to the Community. My scan of a sample of meeting records found nothing that concerns me. What I didn’t see was explicit input from users, and I could not determine if any of the attendees were there to represent users. Noting that a lot of the recorded topics/work would effectively be invisible to users. As such a user representative may not add value, or be relevant, to the monthly meetings.

I found this statement 4 December 2023:

Blockquote Feature Requests
On that note, a lot of recent update changes take place under the hood, not being very visible to IPFire users. We should strive at also fixing the small things in the WebUI that make user’s life easier.

So the Developers have recognised the WUI needs fixing well before this thread was started. That is good. What I have not found (or looked for) is a way for users to submit proposals for changes to the WUI.

What to do?
Given that the developers have already discussed the need to fix bits of the WUI, I could create a simple spreadsheet of change proposals and post it onto a new thread. I will add any proposal from any user and repost the updated spreadsheet. It is basic, almost crude, but should provide the Developers with a list of fixes that users have identified.

Nothing will happen with this unless the Developers fully buy into all of this.

Other Actions
That would still leave other things that need actioning. Recruiting more developers being one of them. One option might be to approach a University teaching computer science or similar. One of my Professors used to set assignments to write code for a in-Taxi terminal he was working on. An open source project like ipFire would provide tutors with a real world example they can use to write student assignments. I am on the wrong side of the planet to organise that. Again, any such effort would require buy-in from the Developers.

2 Likes