Replies: 2 comments
-
I'd add an obvious thing, but important enough to be mentioned: |
Beta Was this translation helpful? Give feedback.
-
Here is a new PR #943 for this topic. Mentioning it here for transparency, as it should be reviewed as part of this thread. |
Beta Was this translation helpful? Give feedback.
-
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
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;
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.
Beta Was this translation helpful? Give feedback.
All reactions