It occurred to me in reading these different discussions on documentation that to me documentation is something static that has been "blessed" by the community as the sanctioned document. But something like bug reporting, or asking for help in installation, that this is a different interaction completely. In a sense this is community discourse.
I don't feel strong about using the word "discourse," but I think that there will naturally be different levels of discourse. This list may not be exhaustive, but I hope it will be illustrative of those scenarios to which I'm attempting to call your attention.
List ONE:
I can see a natural inclination for:
1. Discourse between core devs.
2. Discourse between core devs and community devs.
3. Discourse between community devs.
4. Discourse between core devs and podmins.
5. Discourse between community devs and podmins.
6. Discourse between podmins.
7. Discourse between podmins and pod users.
8. Discourse between pod users (i.e., not on the stream).
9. Discourse between community reps and pod users.
10. Discourse between community reps and podmins
11. Discourse between community reps and community devs
12. Discourse between community reps and the media.
List TWO:
I'm not sure that there is a natural inclination for:
A. Discourse between community reps and core devs
B. Discourse between core/community devs and pod users.
C. Discourse between core/community devs and the media.
I'm not saying these last three cannot happen, but I can envision that tools that encourage discourse between these groups, as indicated in the second list, may hamstring members of each group. These channels if used at all will not be used frequently. Because they are optional, they shouldn't have the kinds of infrastructures that scenarios on the initial list might require.
As you can see from the long list, grouping such complex interactions into documentation is setting us up for a big fail, IMHO.
In addition, if you look at my first list, something like Bug Reporting might manifest as in a few ways...There might be two legs to Bug Reporting. The initial leg could be pod users to podmins, or pod users to community devs or pod users to community reps. Then it might be passed from podmin to core/community devs. or betwen devs. An infrastructure that is multi-leveled for something like bug reporting should be multifacted so that anyone can report a bug and that bug will funnel through the right discourse channels. The way that this happens optimally has to do with our culture.
For example I'm sure a core dev doesn't want a new pod user who doesn't even know the word for something going on in the UI to report it directly to a dev. It's not part of the culture. BMM is a kind of discourse that would go on between comm devs and core devs. Getting Help might happen between pod users, or between podmins and pod users, or community reps.
What I'm trying to say here, is that we need to prioritize the kinds of discourse that will empower the culture and minimize negativity, We can't have a one-size fits all approach. This is my biggest beef with making pod users go offsite to find help or report bugs at git hub, as an example of ineffective discourse that does not empower our culture.
Discourse happens between people:
person(s) <--> person(s)
Documentation is a little different:
person(s) <--> document(s) <--> person(s)
As such these kinds of interactions would require different infrastructures, different tools.
So I think we have to discuss:
What kinds of interactions we must have and we must encourage in order for D* to flourish, and those we may want to prohibit or give less priority.
THEN find tools or build tools to fit that interaction's need.
Again, we should identify what kinds of interactions we agree will support a vibrant community and then select tools that fill those gaps.
What I see happening is that we are looking at tools first before deciding what we actually need them for. It's bass ackwards, friends!
tortoise · Tue 11 Sep 2012 3:16AM
It occurred to me in reading these different discussions on documentation that to me documentation is something static that has been "blessed" by the community as the sanctioned document. But something like bug reporting, or asking for help in installation, that this is a different interaction completely. In a sense this is community discourse.
I don't feel strong about using the word "discourse," but I think that there will naturally be different levels of discourse. This list may not be exhaustive, but I hope it will be illustrative of those scenarios to which I'm attempting to call your attention.
List ONE:
I can see a natural inclination for:
1. Discourse between core devs.
2. Discourse between core devs and community devs.
3. Discourse between community devs.
4. Discourse between core devs and podmins.
5. Discourse between community devs and podmins.
6. Discourse between podmins.
7. Discourse between podmins and pod users.
8. Discourse between pod users (i.e., not on the stream).
9. Discourse between community reps and pod users.
10. Discourse between community reps and podmins
11. Discourse between community reps and community devs
12. Discourse between community reps and the media.
List TWO:
I'm not sure that there is a natural inclination for:
A. Discourse between community reps and core devs
B. Discourse between core/community devs and pod users.
C. Discourse between core/community devs and the media.
I'm not saying these last three cannot happen, but I can envision that tools that encourage discourse between these groups, as indicated in the second list, may hamstring members of each group. These channels if used at all will not be used frequently. Because they are optional, they shouldn't have the kinds of infrastructures that scenarios on the initial list might require.
As you can see from the long list, grouping such complex interactions into documentation is setting us up for a big fail, IMHO.
In addition, if you look at my first list, something like Bug Reporting might manifest as in a few ways...There might be two legs to Bug Reporting. The initial leg could be pod users to podmins, or pod users to community devs or pod users to community reps. Then it might be passed from podmin to core/community devs. or betwen devs. An infrastructure that is multi-leveled for something like bug reporting should be multifacted so that anyone can report a bug and that bug will funnel through the right discourse channels. The way that this happens optimally has to do with our culture.
For example I'm sure a core dev doesn't want a new pod user who doesn't even know the word for something going on in the UI to report it directly to a dev. It's not part of the culture. BMM is a kind of discourse that would go on between comm devs and core devs. Getting Help might happen between pod users, or between podmins and pod users, or community reps.
What I'm trying to say here, is that we need to prioritize the kinds of discourse that will empower the culture and minimize negativity, We can't have a one-size fits all approach. This is my biggest beef with making pod users go offsite to find help or report bugs at git hub, as an example of ineffective discourse that does not empower our culture.
Discourse happens between people:
person(s) <--> person(s)
Documentation is a little different:
person(s) <--> document(s) <--> person(s)
As such these kinds of interactions would require different infrastructures, different tools.
So I think we have to discuss:
Again, we should identify what kinds of interactions we agree will support a vibrant community and then select tools that fill those gaps.
What I see happening is that we are looking at tools first before deciding what we actually need them for. It's bass ackwards, friends!