You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a community stakeholder
I need a "clear process" for engagement and participation
so that I can testify to my requirements and make technical contributions
I propose the effort would benefit from a simple, formal and transparent process where enhancement proposals are discussed by the community and promoted into the spec (or not) based on evident technical merit.
The OSI approach to Open Standards is probably a useful guide:
Yes, this could (probably should) be implemented with GitHub tickets, so we don't necessarily need new features to support this. The suggestion is that we adopt a pragmatic workflow for proposing, discussing and deciding on changes, and the workflow and decision making should be compatible with a community-led process.
I would consider the community process a success in the following scenario:
Given I am a community member with an enhancement idea
And I have read the public web content about the community process
When I submit my enhancement proposal (in the form of a GitHub ticket)
Then I understand how it will be assessed on technical merit
And the discussions of technical merit are conducted in the open
And I am able to participate in the discussions of technical merit
And I understand that the decision to accept or reject the enhancement proposal was made in a fair and reasonable way (even If I do not agree with the decision)
The text was updated successfully, but these errors were encountered:
I just wanted a compact unambiguous description of what constitutes a successful community process. Definition of Done and all that. Let's call it "psudo-gherkin", because obviously there's no intention to have an automated test for it.
This elaborates on https://github.com/ausdigital/framework-docs#how-to-participate (and extends #2).
I propose the effort would benefit from a simple, formal and transparent process where enhancement proposals are discussed by the community and promoted into the spec (or not) based on evident technical merit.
The OSI approach to Open Standards is probably a useful guide:
Yes, this could (probably should) be implemented with GitHub tickets, so we don't necessarily need new features to support this. The suggestion is that we adopt a pragmatic workflow for proposing, discussing and deciding on changes, and the workflow and decision making should be compatible with a community-led process.
I would consider the community process a success in the following scenario:
The text was updated successfully, but these errors were encountered: