With more operators atlas development needs to consider their opinions and inform them about (planned) changes. This is especially true for orion and items that affect all deployments like Joystream/orion#245.
In the past JSG made decisions over the head of other operators which led to disenfranchisement. Tailoring atlas on the needs of the gleev team only introduced roadblocks for new adoptions like #6525.
Going forward new releases have to gather feedback from operators already before feature freeze.
Operators need to be queried regularly about their (user's) wishes (at least once per term). Then features are prioritized based on available budget (by apps and council).
For new features consider to make them optional for users / operators via (admin) settings. This will ensure modularity and keeps the app versatile.
In case of diverging interests there can be multiple feature branches operators can select to merge. The team should rebase them after each release.
The communication process for this needs to be transparent to enable asynchronous communication and motivate to get involved. Operators are invited to create issues and promote them to the council to get funding, ideally on the forum for others to share opinions: Category: Atlas
In open source projects it is common to use milestones to group issues. This will be available once JSG grants privileges.
With more operators atlas development needs to consider their opinions and inform them about (planned) changes. This is especially true for orion and items that affect all deployments like Joystream/orion#245.
In the past JSG made decisions over the head of other operators which led to disenfranchisement. Tailoring atlas on the needs of the gleev team only introduced roadblocks for new adoptions like #6525.
Going forward new releases have to gather feedback from operators already before feature freeze.
Operators need to be queried regularly about their (user's) wishes (at least once per term). Then features are prioritized based on available budget (by apps and council).
For new features consider to make them optional for users / operators via (admin) settings. This will ensure modularity and keeps the app versatile.
In case of diverging interests there can be multiple feature branches operators can select to merge. The team should rebase them after each release.
The communication process for this needs to be transparent to enable asynchronous communication and motivate to get involved. Operators are invited to create issues and promote them to the council to get funding, ideally on the forum for others to share opinions: Category: Atlas
In open source projects it is common to use milestones to group issues. This will be available once JSG grants privileges.