Community feedback - help shape the development and contribution lifecyle

[jordy2254]

In conjunction with @kkovaletp we have been talking about the best view forward for photoview, and to ensure that we are as community driven as we can be. This conversation is to spark the initial talks on what we as a community would like for the future of photoview from a contributions perspective. Below is the workflow we have discussed so far but we are open to opinions, feedback and other ideas and that is exactly what this conversation is for!

Not just code

Don't forget contirbutions don't have to be code, there's a documentation site, setup help, community support, code reviews and more. If you have the skills it doesn't matter how small the contribution is welcome!

Bug

The bug flow is the simpler of the 2 flows, and will most likely jump straight to development unless further discussion on architectual changes are required

Overview

development -> code review

New features

New features are intended to be the longest flow as we want to ensure there is no time wasted by contributors. And that anyone can contribute to photoview.

Overview

Discussion -> Dev Approach -> Development -> Code Review

NOTE: Some features if basic may be able to skip stages.

User flow

A new feature will start it's life an issue tagged as such, the initial author should highlight what they want from the feature. Then from this interested community members can spark discussion and ideas about how this should work from a user flow perspective IE;

• User navigates to settings
• There is a specific section for x
• There will be and add button next to the title

Development approach

When sufficient conversation has happened, a label will be added to the ticket indicating it is ready to be picked up for a development approach, this gives someone the ability to investigate the existing architecture and build and right a high level solution overview, doing so ensures that work is implemented into the system in a maintainable way and also hopefully reduces the amount of rework when a code review happens. The development doesn't have to be done by the same person and hopefully this will give less experience member's a chance to contribute to development.

Development

When the development approach has been written and signed off it will be time to develop the work. Again, this doesn't necessarily need to be done by the same person

Additional states

Help requested and some other tags are being discussed so that we can mark PR's & issues as requiring support by the person doing them should they get stuck. This strives to produce

Code review

As all PR's the code will the be reviewed by the community and maintainers before being merged ensuring the change meets the requirements, dev approach and integrates correctly into the system. This will hopefully drive community spirit and help people get support if they need rather than giving up.

Overall

The changes above should provide a much better community interaction and allow people to work on different things as they need to. New tags will be created for the various change so that we can properly evaluate tickets and filter down appropriately to see stages/requested help etc.

[kkovaletp]

I'd add an obvious thing, but important enough to be mentioned:
There will be a list of requirements for the new code (bug fix or new feature) to pass the code review stage. I hope that we can draft and finalize it here as part of the discussion.
It should include minimal code coverage % be unit tests (the value is yet to be defined) - this is an obvious part. But what might be less obvious, is the documentation update, readme update, and similar things - not every product increment (PI) needs them, but most new features do: it is good to enhance Photoview with new functionality, but users should know about its existence and know how to use it, as if not, most probably only the contributor and a few more people will use them. I guess that this is not what contributors want when spending their time on feature design and development.
What do you think? Let's start a discussion)

[kkovaletp]

Here is a new PR #943 for this topic. Mentioning it here for transparency, as it should be reviewed as part of this thread.