Plan for new development

[AdamPS]

Branches

I propose to introduce some minor interface changes as part of developing some new features and bug fixes. Therefore I suggest to move to a new major version v3. I intend v3 to become available within a few months. So my preference is like this, which should minimise the amount of merging needed.

1. Rename branch feature-safeeyes-3 (stale) to old-safeeyes
2. Use master branch for v3 development
3. Create a new branch for v2 if we need to backport high-priority bug fixes.

Roadmap

• My top priority is to fix some 'bugs' where the breaks don't come when I expect/want them do.
• Based on my earlier experiences I believe this will be easier if making some minor interface changes.
• Features are good, however it can still be improved, I have ideas for more.
• Visually the program is already good.

We can link issues here if they should be fixed before releasing v3 (i.e. they cause interface changes). We could also create a v3 tag for that purpose.

@slgobinath How closely do you want to be involved? You are very welcome to review in more detail, or if you prefer, leave me to work myself.

[slgobinath]

Thanks @AdamPS 🙏

I won't be able to involve much and I am happy to leave it to your leadership. Totally agree with your proposal.

[nifadyev]

Hey @AdamPS , sorry for disturbance, just wanted to know if you need any help with maintaining the project. I can deal with current issues and take part in developing V3

My background is 4 years of Web development using Django. During that period I dealt with many non-web related tasks like Docker setup, writing documentation, changing CI/CD and so on.
I'd love to help and to be involved in making a tool which I use daily.

P.S.: @slgobinath , thank you for creating SafeEyes

[AdamPS]

That's great, I would welcome help, as I've been pretty busy. The next step is #552 and I'm sure the community would appreciate your help with that.

I suggest that you start by actively making useful comments, reviews, pull requests, etc. You can let me know which PR are ready and I can commit. Once you have become a successful active contributor then we can ask @slgobinath if he would make you a maintainer.

[nifadyev]

Thanks, sounds like a plan. I will start from reviewing existing PRs and then dealing with issues. It would be useful to write a contribution guide for other enthusiasts like me.

[AdamPS]

Great, the contribution guide is a good idea. However I'm still trying to figure things out for myself, so I guess we'll have to learn together😃.

[nifadyev]

Hey @AdamPS , I've looked into project codebase, relevant issues and V3 drafts and I think it would be wise to start planning V3 as soon as possible. There is no point fixing old deprecated logic which will be replaced soon (hopefully). What are your thoughts about it?

[deltragon]

Hello @AdamPS,
I am open to becoming a co-maintainer for this project. I have already implemented a port to gtk4, along with other improvements and wayland fixes.
In the case this project doesn't see any movement in the next few months, I am planning to fork this project under a new name and maintain it there until this project is revived.

[slgobinath]

Hi @deltragon and @nifadyev ,
I just saw your comments. I already saw your PRs and reviews and you guys are already contributing a lot to improve this project. Happy to see the Safe Eyes community growing with more maintainers. Sent the invitation to both of you.

@archisman-panigrahi shall I add you as well to the maintainer list?

[archisman-panigrahi]

Yes, I will be happy to be a maintainer

[nifadyev]

Hey @slgobinath , thank you for your trust, it's a challenging opportunity, but I'm afraid I won't be able to collaborate any time soon. I can review PRs and check issues and if that small amount of activity is OK for now, I will happily become a maintainer.

[nifadyev]

Hi @slgobinath , were you able to read my previous comment? The invitation will be expired in 2 days, and I'd like to receive your feedback before accepting/rejecting the invite.

[slgobinath]

Hi @nifadyev ,
Reviewing the PR is a lot of work. Please accept the invitation.

We all have other priorities. Having more people will help us keep the project alive even if some people are busy.

[AdamPS]

Sorry everyone I was busy and I only just found time to come back to safeeyes. I'm glad that there are now more maintainers and we can share the work.

[nifadyev]

Hey everyone, I would suggest converting this issue into discussion and slowly start working on future plans there

[archisman-panigrahi]

I just converted it into a discussion

[archisman-panigrahi]

Suppose there is a PR, and it looks good. Shall we wait for approval of all maintainers before merging? Otherwise, how shall we proceed?

[deltragon]

I think I would have decided on a case by case basis - if the PR seems small and self-contained, I think it's enough if one maintainer agrees.

For bigger changes/refactorings, I do think it makes sense to have at least two maintainers looking over it.
This is also why I haven't merged my own PRs yet - I'd prefer if someone else has a look as well.

[nifadyev]

+1 for @deltragon . If there is some flexible approve rules on Github, we should definitely use it. For example, if PR contains more than 200 changed lines, 2 approves are required, otherwise - 1

[deltragon]

I have started using the "assigned to" feature on github issues to assign myself issues that I plan to work on (or in some cases, already have WIP patches).
If it should happen that I let an issue lie for too long, and you want to take it over, please notify me, so I can send you my work if there already is some.

[nifadyev]

We shall also migrate Github Project till August 23, because classic project will be deprecated.
Or it would be better to create Github project from scratch (if it would be helpful, of course)
Any thoughts?

[nifadyev]

Hey @slgobinath , @archisman-panigrahi , @deltragon

I would suggest we discuss the future of the project. Currently, it is in “maintenance” mode (reviewing existing issues and PRs) but we shall think about next plans.

I suppose that every one of us should express thoughts about safeeyes future and then we prioritize them and make the decision.

For example, here are my thoughts about next steps in safeeyes lifecycle:

• More automation including PR and issue templates, CI checks and validations, releasing packages on different distros, bots to manage issues/PRs
• Unit tests on all supported python versions using tox/nox
• Somehow test package on different systems
• Type annotations and other features of modern python versions
• Modern tools for development (dependency management, package building, linters, formatters, validators and code checks, pre-commit)
• Fulfil community standards
• Divide package into core, cli and gui parts (just a personal preference to tuis and cli tools)

[nifadyev]

Hey @archisman-panigrahi , thank you for your thoughts. As I said, these are opinionated thoughts, so it is fine if we have different opinions. So if you have anything which is not stated before, please feel free to share it with us

Regarding your comments:

• Agreed about releasing packages
• Unit tests will definitely reduce errors, make review easier and serve as self-documentation. nox/tox are used for basic check that code is working on specified python version
• OK, sounds good. I am not familar with package testing, so this topic should be researched better if necessary
• Type annonations are very helpful during development. I personally find them very useful because of IDE hints, "simple" checks without need of running code and relevant function documentation. You can read more in this PEP. So called gradual typing allowing annotating python code step by step, without regression
• I don't know about your experience with any of these tools but if you've used them once, it is very difficult to develop without them). Basically, they encourage every contributor to write clean, simple, readable and similar code. Moreover, they easy PR reviewing, because some checks are performed by CI and there is no need in reviewing code style
• Actually, safeeyes is still missing contributor guide, PR template and security policy
• Fair point, as I said, this is just personal preference but better isolation between not really related logic is highly encouraged. Who knows if safeeyes GUI will be but core will stay the same

[archisman-panigrahi]

As I said, these are opinionated thoughts, so it is fine if we have different opinions

👍

Agreed about releasing packages

No, I did not agree about releasing packages. I said, it is best left to the distro package maintainer. If you feel that some distro is lacking behind, try to join the distro's packaging team and take responsibility for safeeyes at the distro level. That does not mean we will release packages in GitHub as the safeeyes development team.

(For an example: Instead of offering an RPM in GitHub, try to join the Fedora packaging team, and ensure that safeeyes is available via yum).

[archisman-panigrahi]

Actually, safeeyes is still missing contributor guide, PR template and security policy

I am unsure what these guides should ask for, so if you have any ideas, please share

[nifadyev]

My bad, I've meant that I agree about your opinion regarding releasing packages strategy, no Github packages release

I am also not familiar with contributor guide and other community standards, it should be analyzed and made in separate issue

[nifadyev]

If everyone have shared their thoughts then I suggest we decide on all discussed thoughts
@deltragon , @archisman-panigrahi

• Automation (PR and issue templates, CI checks and validations, bots to manage issues/PRs) - without package releasing
• Unit tests on all supported python versions using tox/nox
• Somehow test package on different systems - manual, but it is better to write some checklists for testing
• Type annotations and other features of modern python versions
• Modern tools for development (dependency management, package building, linters, formatters, validators and code checks, pre-commit) - should be discussed separately like this PR
• Fulfil community standards - create issue for discussion and implementation
• Divide package into core, cli and gui parts - No, but some kind of decoupling and contexts separation is encouraged.