3

Given the democratic nature of feature development on Orion, and the pace at which features are being introduced, I propose a feature freeze to be voted on. During the freeze, a renewed focus on the important underpinnings of the browser and development process should occur; it is the work that is deeply unsexy, unexciting, but of utmost importance. My hope is that this suggestion gets enough votes to justify its usefulness to the Orion team, and allow for them to focus on these areas.

Now for the concrete proposal:

  1. All development on new features should be paused for six months. This time should be used for...
  2. Addressing outstanding functional defects in the backlog
  3. Addressing outstanding UI/UX defects in the backlog
  4. Addressing any technical debt through re-factoring, unit testing, etc
  5. Enhancing or re-thinking the regression testing process as to prevent defects from re-appearing in the future (end to end testing process, integration builds, etc)
  6. Stabilizing the underlying WebKit version (no updates unless strictly necessary)

    jmanes While I like the idea in principle, I’m going to “disagree”. Every dev team on the planet would love to take half a year to polish things off and refactor.

    Orion is still in beta and the team has already does releases that focus on regressions and bug fixes, a good example being the upcoming RC. The browser isn’t supposed to be rock solid yet because it’s still being developed. (It also isn’t their main revenue source, with only 800 subscribers)

    Also from a business standpoint, Kagi isn’t profitable until search is at ~ 25,000 subscribers. Shipping features fast is where the money is made, especially with competitors implementing similar features (arc, perplexity, etc). They can’t afford to not ship new features for 6 months while competitors beat them to market.

    Any specific show-stopping bugs should be reported on the forum, and usually get fixed within a few release cycles.

    I am not disagreeing with you per-se, just suggesting that the timing isn’t right. If the browser was no longer in beta I would 100% expect a focus on polish over new features.

        ForumNinja404

        Shipping features fast is where the money is made, especially with competitors implementing similar features (arc, perplexity, etc)
        There's no point of shipping features if the browser isn't stable enough to use for the majority of users. Yes, features matter, but enacting a feature freeze to focus time and effort on refactoring code and building/doing comprehensive testing can provide many long term benefits for the project in the future. By adopting a feature freeze and doing an "audit", they can build more new features in the future with added stability and less bugs.

        It's really a question of what the userbase/Kagi wants: less bugs overall and no new features for a period of time, or new features faster with more bugs -- and once Orion is ready to go into post-beta there may be more refactoring to be done, which may cause more bugs, etc. This is why I believe it's important to do this feature freeze now versus near post-beta release.

        Just going full speed developing features without using a more cautious approach may make it harder on the devs to build a maintainable and stable piece of software. I think overall, enacting a feature freeze, refactoring code, implementing rigorous testing, etc can help the project in the long term versus cranking out features while many bugs are in the backlog that could be resolved by doing the aforementioned practices.

        Basically:

        • Prioritizing quality and stability can increase user trust and loyalty
        • Continuous feature development without addressing technical debt can lead to an unmaintainable codebase.
        • Investing time and effort in refactoring and extensive testing can save development time and work in the future.
        • Business strategy: a buggy, unreliable product can turn of potential customers (subscribers).

        To address technical debt the Orion team could pursue the following practices:

        1. test driven development
        2. continuous integration/continuous delivery/continuous testing
        3. code review
        4. static code analysis
        5. pair programming
        6. defensive programming
        7. vcs (git)
        8. behavior driven development

        Additionally refactoring code should follow the principles of simplicity (simple abstractions), clarity of requirements/specification, and extensive testing. Some other things (free ideas) that could help:

        1. Modularize the codebase
        2. Documentation for developers to make development easier for new team members (and existing ones!) This includes: project overview, high level architecture, components, design philosophies, development guides (setup, coding style, etc)
        3. A clear roadmap (which bugs will be fixed at what release/version)
        4. Rigorous code review process
        5. Delegation (similar to Linux) once/if the development team becomes larger

            jmanes The idea is not without merit. Also note that 90% issues reported here are bugs to begin with, and 90% of things shipped in our releases are bug fixes already. It is not like 90% of our time is going into new features, it is the other way around already (latest release is an exception as we decided to ship a few popular features that have been waiting for two years). Between chasing WebKit bugs, macOS bugs and Orion bugs in a 3 person team, there is only so much you can do.

              No one is typing