Talk:Workgroup:style guidelines

From WikiEducator

Jump to: navigation, search

[View source↑]
[History↑]

Contents

Thread title	Replies	Last modified
Accessibility	0	09:44, 16 May 2010
Including statements into charter about localisation	1	12:41, 23 October 2009
Guideline adherence/opt out tool	3	12:59, 30 September 2009
Modification to proposal style to allow better use of whatis template	9	03:08, 31 July 2009
What is the approval process we should use?	8	12:23, 30 July 2009
Moving some conversations	2	13:30, 28 July 2009
Not using LiquidThreads	1	13:16, 28 July 2009
Style guide rationale	0	09:29, 24 July 2009
How to use this space	0	07:05, 24 July 2009
Styles and content types	3	17:41, 19 July 2009
Thoughts on related issues -- over & above style guide recommendations ......	11	17:00, 19 July 2009
Sarcasm or humour?	2	14:58, 15 July 2009
General format for guidelines	0	14:54, 15 July 2009

Accessibility

Is Accessibility directly relevant to this workgroup? If so, please take this over.

KTucker (talk)‎

Including statements into charter about localisation

I'm wondering if it could be useful to include statements in the charter that clarify the scope of the style guide, as it relates to various localisations. I never intended them to apply to any other localisation than the English version, nor do I really think it is our responsibility, as we are not a part of their individual communities. Does anyone have suggestions for what I can add to the charter that clears this up?

Jesse Groppi (talk)‎

Good point Jesse. Perhaps the "Languages policy/ guidelines" is a separate concern. Link to related discussion.

Hint: Add a "Boundaries" section - see the boiler plate for workgroup charters - Boundaries - and specify the scope of this endeavour.

KTucker (talk)‎

Guideline adherence/opt out tool

So we eventually need to come up with a way that users may disclose his or her awareness of the guidelines, and in what way the page adheres or opts out of them.

The idea that has been brewing in my mind this week is of an icon that displays in either the infobox or upper right hand corner of the page. It would display one icon/colour for full adherence, and another if any part of the guidelines are opted-out of. On mouseover, a box would appear that describes what, if anything is opted out of, and in what way any specific guidelines are adhered to (such as with regional spelling choice).

Any thoughts? This may/probably does require JavaScript, and I don't know if we have that enabled or not. Do we have a WikiEducator capable of writing the code for a wiki environment, or should I go to my go-to-guy for this sort of thing (The chap that has written most the AJAX and plain JS currently used in WoWWiki) ?

Jesse Groppi (talk)‎

I like the idea for an icon to indicate how the guidelines are being used in a specific instance. I can offer no help as to coding for such an application, but have you seen Template:Learning Design? It uses an icon (a fourbox square) to communicate stages in the design process, separately for learning and content design. Thought you might be interested.

ASnieckus (talk)‎

Heh, I've just realised what you meant by the fourbox square! I just saw it used elsewhere, and yes, it has inspired me as useful in this application. I've an idea for how to design this, but I need to go back and find the CSS code I had looked at before. Look for it in one of my dev pages, soon.

Jesse Groppi (talk)‎

hehe. yay, for the fourbox square.

ASnieckus (talk)‎

Modification to proposal style to allow better use of whatis template

So, I made this template to address the issue of including users in the discussion that are newer to wiki terms and syntax. However, because of the style in which I made the new proposal organisation means I cannot use the template within the main guideline phrase, where it would be most useful.

I think I'd like to adjust that style a bit with the guideline specifics remaining in the header, except the main phrase is bolded at the top, and the Mytitle template is only used to shorten the title of the sub-subpage.

It would look a bit like this.

With details.

And examples:

like so

Then approvals[edit]

Any complaints against me doing so?

Jesse Groppi (talk)‎

This works for me. I'm interested to see how it all works.

I'm quite new to all of this, and took a few minutes earlier to try out approval and discussion on some of the proposed guidelines. The layout is simple and very understandable -- well done. I did notice that I particularly enjoyed and benefited from reading your quick rationales in the discussion section -- my wiki concept map is more detailed than before. I wonder if a rational should be added to the main section of the guideline template. Or will the discussion be easily accessible from the main guideline page? I think later newcomers might be similarly interested. Just some thoughts. --Alison Snieckus 01:28, 25 July 2009 (UTC)

ASnieckus (talk)‎

Alison,

The proposals are created using an inputbox that fills the new page with the content at Help:Guideline proposal. So, when someone suggests a new guideline, the inserted content explains that a rationale should be included first thing in the discussion section. Does that fulfill your concern on it?

Discussion is accessible from the central style guide within two clicks of a mouse. In the guide is the same navigation template found in the workgroup charter, the proposal pages, and the talk pages.

Jesse Groppi (talk)‎

Jesse, Thanks for explaining this a bit more. The help page is very clear and concise. Now I see why you posted a rationale as the first point under discussion. Just want to say (again) that I like the rationales.

I don't really have a concern, just thinking that new members looking to use the finalized style guide could well benefit from reading a guideline's rationale (as I have) and they may not know to go looking for them. I'd vote for keeping them on the guideline page in the final document (if there was a way to do so without cluttering things up). Just a thought.

ASnieckus (talk)‎

I don't see why there shouldn't be a rationale on the final guide, but you're right that it may bog things down. We shall just have to experiment with it when the time comes to determine how the guide will be formatted.

Jesse Groppi (talk)‎

I'm going to go ahead and make the changes since I haven't heard any complaints after a week. :)

Jesse Groppi (talk)‎

In response to a concern about the readability of our proposals, I designed this table to display them in a more understandable fashion. You can see the implementation at User:Jesse Groppi/sandbox01. Any comments?

I've also designed an easy template to list the proposed guidelines, which you can see implemented at the sandbox I linked above. The code is at User:Jesse Groppi/dev04.

Jesse Groppi (talk)‎

As I've said elsewhere, I like the table. In addition to improved clarity, I like that we are expected to include examples.

One thought, I think the additional points on the guidelines that have been proposed so far aren't really 'description' of the guideline. In my mind they're more exceptions, limitations, additional situations.... Is there a word other than 'description' that would better fit the collection of possible additional points?

ASnieckus (talk)‎

What about "additional information"?

Jesse Groppi (talk)‎

Yes, "Additional Information" is better suited to the contents than "Description". I agree.

ASnieckus (talk)‎

What is the approval process we should use?

This is the process I'm imagining:

30 days of active discussion
- This doesn't mean 30 days from the point of the first rationale, instead, a facilitator would have to make a judgement call about when the active discussion began
- It should be noted on the proposal's page, and on the proposed guidelines list, when the active discussion began and when it will open up for approval
- Perhaps the time bit could be replaced with, or supplemented with a minimum number of discussion participants.
Users voice their approval or disapproval
- The range of votes would be:
  - Approve - The user approves of the guideline the way it is
  - Conditional - The user approves of the guideline on a condition that must be met. These should be addressed by facilitators, and a good attempt must be made to meet the conditions within reason. When the conditions are met, the user should replace their conditional vote with an approval vote
  - Disapprove - The user doesn't think this guideline is at all necessary.
- A collection of templates would be used that I can quickly whip up that put headers on the proposal page explaining what each vote means, and the individual vote templates would include a signature and possible explanation.
- It needs to be determined how many approvals there must be, and what percentage of the total votes must be approvals before going on to the next step.
Here would be a place to put in a Community Council step, if we feel that is necessary.
The guideline gets added to the official document.

Jesse Groppi (talk)‎

Hi Jesse,

These proposals seem fair and reasonable, and I think that they would work rather well in the WikiEducator community.

I've been thinking about the Community Council step --- I don't think that its necessary for Council to approve the individual guidelines. Style guidelines are operational -- not governance. I would suggest that we consider developing a generic policy proposal which outlines the process you have described for developing "official guidelines".

In other words Council considers the process for the development of guidelines -- not the approval of individual guidelines. I think the approval of guidelines is a community decision. Consequently -- assuming Council approve the process -- "official" guidelines can be approved by the community.

I would also recommend that we think about a process for appeal or refinement of guidelines. Any thoughts.

Great work Jesse -- this is really coming together rather nicely :-)

Cheers

Mackiwg (talk)‎

Okay, so as a refinement:

30 days of active discussion and a minimum of 5 discussion participants
minimum of 10 approvals accounting for 2/3 the vote
the guideline is officially ratified

What do you think of my minimum numbers and approval percentage?

My thoughts on appeals and refinements are that they ought to go through the exact same process. The desired outcome should be stated and given a rationale and description, then the above process is observed. This would be done through this same workgroup.

Jesse Groppi (talk)‎

Hi Jesse,

I think the minimum numbers for approval are fine.
How are conditional votes counted? What do we do in the case of refinements after votes have been cast or conditions have been met resolved? Do we want a procedure to follow up with the holder of a conditional vote -- to recast their vote within a reasonable time in cases where the condition has been met in subsequent refinements? etc. This is always a challenge with voting in a open wiki environment -- because the draft guideline can be amended, which technically would require a new round of voting. This is where professional judgement of the convenor of the guideline is required. I don't think that a guidelines process should become overly mechanistic -- we just need to be clear up front how the process will work.
The inclusion of an appeal/refinement process will reduce the "red tape" and problems associated with valid votes in the case of minor refinements to the guideline after a vote is cast. The aim is the "spirit of consensus" with a guideline rather than absolute mechanics of legitimate voting. Stating this upfront in the policy for developing guidelines will help resolve any future disputes.
My experience of wikis in general and WE in particular is that specifying a minimum number of discussion participants becomes an arbitrary number. Reasonable opportunity and transparency to participate is more important than the actual numbers of participation. My experience of WE is that we typically have very low levels of discussion on things which people generally agree with -- however, a controversial issue will encourage passionate discourse :-). In this regard - I'd recommend removing the minimum number of discussion participants -- but keep the minimum period of discussion. Its perhaps better to have a policy requirement that once every month, or six weeks or whatever time frame, there will be a post to the main WE discussion forum listing the style guideline proposals to be discussed and that members should provide their feedback by a specified date -- eg 30 days (are those working or calendar days?).
The fact that there is an open voting mechanism will ensure that folk can have their say -- I think the question is, do we encourage and or accept voting within the 30 day discussion period?

Good thinking Jesse -- shall we try and have a draft policy proposal for style guidelines ready for the next Council meeting scheduled to start on 7 September :-)?

Cheers

Mackiwg (talk)‎

Conditional votes: I think if the condition has been met, but the user hasn't moved their vote to the approval section, it should be considered an approval. If it has not been met, the conditional vote is equivalent to a disapproval. A facilitator should always reply to the vote to say whether the condition has been met or not.

Good suggestion -- I agree with this. --Wayne Mackintosh 03:17, 28 July 2009 (UTC)

Minimum discussion participants: Yeah, the number is usually arbitrary, but the point is to attempt to show the potential opinions of the majority of the users on the wiki. I would prefer to stress that during the discussion period, even if there's a general agreement, that everyone attempts to say what he or she thinks of the guideline. If you're in agreement, why not say why or what about it you especially like?

I agree with the intent -- and we should always promote and encourage discussion! Take an example of a pretty straight forward style guideline that doesn't attract the minimum discussion levels. Does that suggest that the guideline doesn't go ahead? What happens if there are not 5 discussion participants? Just thinking practically here --- as long as we have a mechanism for a reasonable period of time to discuss, we should move forward. --Wayne Mackintosh 03:17, 28 July 2009 (UTC)

WE discussion group reminders: Atm, yes, there's enough going on that we'll probably be using the discussion group more often than every 30 days, but in the future, the creation of guidelines will likely slow to a dead crawl, and the likelihood of new happenings every 30 days is rather low. I was intending to notify the discussion group whenever major changes occurred with the planning and organisation, approximately five days before a proposal goes to vote, when it goes to vote, and when the proposal is formally approved. I was intending 30 calendar days from the start of discussion, and I think I'm going to create a template for the proposal list that includes title, status, and date voting opens, to make it easier to keep track.

I was thinking more of a mimumum period for open discussion once a batch of guidelines have been announced on the main list -- as a means to overcome a situation where noone comments ;-) --Wayne Mackintosh 03:17, 28 July 2009 (UTC)

Voting during discussion period: I would rather not see voting until after the discussion period. I feel this way because I think it's in everyone's benefit to observe the discussion before making a decision, or influencing others with their decisions. I would not like to see early votes deter anyone from speaking his or her mind. I do see a potential for a vote, such as a council member's, being influential in that way.

Makes sense to me -- we ,ust just communicate this clearly in the policy guidelines --Wayne Mackintosh 03:17, 28 July 2009 (UTC)

I think the timing for drafting this proposal is great. How should it be presented?

As a policy proposal for developing guidelines -- see the emerging drafts on the Workgroup on Workgroups. We have a charter, if we develop a draft policy proposal for the process this could be tabled at the next council meeting :-) --Wayne Mackintosh 03:17, 28 July 2009 (UTC)

Jesse Groppi (talk)‎

It is perhaps my own perfectionism as a writer that leads me to insist on hearing as many thoughts as possible. ;) In writing, it is often more important to hear what is most effective rather than what does not work. A writer will often agonise over the placement and use of each individual word before settling on a sentence. It is in my nature to be incredibly wary of how words will be interpreted, and this is what leads me to hope for a wider range of feedback.

I am aware, though, that others may see this as slightly obsessive. ;) I'm sure that any issues with wording or a guideline in general will be brought to the workgroup's attention so long as it is made clear that such criticisms are welcome and that there is an open and simple process with which to make amendments.

On the policy proposal, I feel somewhat confused, still. What you're suggesting is a separate page that outlines the method in which a guideline is suggested, approved or disapproved, and amended. That page is what the council must approve of for it to become official policy?

Jesse Groppi (talk)‎

I've created this page as a draft of the policy proposal. Is this what you're looking for? Am I doing it right?

Jesse Groppi (talk)‎

Moving some conversations

Now that we've got all the proposals on their own pages and listed on the proposed guidelines page, the only valid content left there are two conversations we have had. I'm wondering if I should remove the suggested guidelines that are still on the page, and move the conversations to this page so that the actual guide's talk page can be cleaned up and prepared for LQT use not associated with the workgroup. What do you guys think?

Jesse Groppi (talk)‎

Hi Jesse,

I think that's a good suggestion :-).

Cheers

Mackiwg (talk)‎

Move and cleaning up done.

Jesse Groppi (talk)‎

Not using LiquidThreads

This conversation was moved here from another talk page. --Jesse Groppi 00:14, 28 July 2009 (UTC)

I have purposely chosen not to use LQT for the following discussions because there are expected to be a large number of active discussions going on at once. Because of this, I think it is essential to archive closed discussions at the time of their closing, and not to leave behind a summary or heading in order to make sure this page is more readable. I also think it is helpful to the contributors of these discussions that the archived conversations be found in a single location. Not using LQT also allows use of the table of contents to the discussion's advantage, as well as other formatting techniques that help make the page more readable. --Jesse Groppi 05:47, 15 July 2009 (UTC)

Hi Jesse -- We're dealing with a complex structure and process, see my earlier comments which I've copied here for convenience:

mmmm -- I see the challenge, we have multiple stages of development requiring different discussion pages. Perhaps we need a subpage called something like "Proposed guidelines" (e.g. WikiEducator:Style_guide/Proposed guidelines) -- each proposed guideline is listed as a bullet on this with a sub-page link (e.g. WikiEducator:Style_guide/Proposed guidelines/Capitalisation). This sub-page could have a standard template with headings like (1) Guideline proposal (2) Discussion -- if you prefer not to use Liquid Threads (3) Status with options for proposed, suggested for approval, approved when this is moved over to the draft guidelines. This way we treat each guideline as an entity rather than a single page. Hope my description makes sense, if not I could try setting up an example. We could also think about using http://www.mediawiki.org/wiki/Extension:InputBox which on the Proposed guidelines page which would create the subpage and contain the headings and subheadings template for the discussion and approval of the actual guideline --Wayne Mackintosh 05:50, 15 July 2009 (UTC)

Here is an example of what I mean: http://wikieducator.org/WikiEducator:Style_guide/Proposed_guidelines -- hope this makes sense :-) --Wayne Mackintosh 06:32, 15 July 2009 (UTC)

I like Wayne's suggestion of using subpages (regardless of having the discussion in lqt or not). The current format will get unruly very quickly IMHO. Just a quick note on subpages while thinking about it: I have not found the search in the wiki to very robust in finding pages and even worse when there are many levels of subpages. Should WE look into ways to improve the search engine so that it has some additional options like searching for a subpage ( or shortpage similar to how Template:ShortTitle made the titles more reasonable)? Kruhly 20:53, 15 July 2009 (UTC)

Hrmm, well the subpage bit is certainly neater, but I'm worried it may not be very convenient for the random contributor to add new points. I do rather like having them all on the same page, and I know that once we have a working style guide, this discussion area will be much less scary-looking. The subpage idea seems just as unwieldy to me as this, just in a different manner. But, is it what WE users are more comfortable using?

As far as the different stages of development, the vision I had was that when we determine we've a proper body of guidelines prepared, we would remove the in progress comments from Wikieducator:Style guide, then considering it the "finished" copy (though it's never finished-finished). This talk page then gets opened up for any and all discussion on the guidelines, including new proposals which are discussed and ratified all in the one place before getting added to the "final" copy. We would have to redraft the charter to match the ongoing purpose of style guideline proposals more closely.

I may not have that entirely thought out, and I would probably be willing to go the subpage route if it's more likely to be WE friendly. I've just got an inherent disapproval of subpage use :P --Jesse Groppi 23:32, 15 July 2009 (UTC)

We could use http://www.mediawiki.org/wiki/Extension:InputBox to make it easier for users to create the subpage, and also have the option to preload the headings and help text as required. Including an appropriate category in the preload text will help keep track of the new pages created. --Wayne Mackintosh 23:45, 15 July 2009 (UTC)

That sounds like a really good idea. I've seen inputbox put to good use over at Wikia. The only other solution I could think of was having a page just for new suggestions, and a facilitator would need to create the new pages. --Jesse Groppi 00:01, 16 July 2009 (UTC)

Did I get the correct number of colons ;-) With Wayne's WikiEducator:Style_guide/Proposed_guidelines format it looks like all of the proposed guidelines would be on the same page with the dicussions linked to the subpages. The input box would help create new proposal subpages but the new proposal text might need to be added manually to the list on the Proposed Guidelines page. Need to think about this ... as I have not used the inputbox recently. Would having status icons similar to the Whatis template help in indicating how far along the discussion is? Should we give it a go? Kruhly 06:21, 16 July 2009 (UTC)}}

Jesse -- I think that it would be smart to include both -- a subheading on the relevant page for new suggestions, as well as the inputbox for creating new pages. Let the user choose :-) --Wayne Mackintosh 06:41, 16 July 2009 (UTC)

Hi Rob -- I'm not aware of any tricks to automate the link on the page -- this would need to be added manually. However, we could include a temporary category in the preload text which would list these pages. Easy enough for signed members of this workgroup to check the category for new pages and add the link to the main page list of guidelines. --Wayne Mackintosh 06:41, 16 July 2009 (UTC)

Yes, no way to automatically add the subheading to the proposed guidelines page, and the category is definitely simple enough to keep track of. I'm working on it, slowly. Yesterday I had a guest I wasn't expecting, so I spent most of the day with her, and I've been dealing with uni issues as well. --Jesse Groppi 16:07, 16 July 2009 (UTC)

Let me know what I can do to help! --Kruhly 19:09, 16 July 2009 (UTC)

Well I think we're all in agreement on the subpage thing, so, time to cut and paste? --Jesse Groppi 22:22, 16 July 2009 (UTC)

I put the inputbox into the article, and created a new proposal page with it. What do you think? Do you like the use of Mytitle to display the full guideline? --Jesse Groppi 03:27, 17 July 2009 (UTC)

Jesse Groppi (talk)‎

Should we be using liquid threads for this discussion instead of the discussion header? I think I approve of the capitalisation statement but we are in WikiEducator_Talk:Style guide and the page where I originated was Workgroup:style guidelines. So following the statement the guidelines I should have started in Workgroup:Style guidelines? Kruhly 05:08, 15 July 2009 (UTC)

I accidently cut out the note I used in a previous iteration of this discussion. It explained that I chose not to use LQT for these particular discussions for archiving and readability purposes. I will put that note back up. I'm not sure I understand your last question, so I'll just explain why I put the pages where I did. First, the workgroup page is there because that's where I understand the administrative content for the workgroup is supposed to go, according to the workshop guidelines that are being developed at Workgroup:WikiEducator Workgroups. I also needed three more pages: one to display the guidelines as they were agreed upon, and two discussion pages. I wanted to keep the general and workgroup related discussions separate from the guideline discussions for readability of the guideline discussions. Alison suggested to me, during an earlier iteration of the workgroup, that the guide's draft go to this project page (You can see that conversation here). So, I thought it logical the general discussion go with the workgroup page, and the guideline discussion go with the Style guide draft. I'm open to suggestions, though! --Jesse Groppi 05:36, 15 July 2009 (UTC)

mmmm -- I see the challenge, we have multiple stages of development requiring different discussion pages. Perhaps we need a subpage called something like "Proposed guidelines" (e.g. WikiEducator:Style_guide/Proposed guidelines) -- each proposed guideline is listed as a bullet on this with a sub-page link (e.g. WikiEducator:Style_guide/Proposed guidelines/Capitalisation). This sub-page could have a standard template with headings like (1) Guideline proposal (2) Discussion -- if you prefer not to use Liquid Threads (3) Status with options for proposed, suggested for approval, approved when this is moved over to the draft guidelines. This way we treat each guideline as an entity rather than a single page. Hope my description makes sense, if not I could try setting up an example. We could also think about using http://www.mediawiki.org/wiki/Extension:InputBox which on the Proposed guidelines page which would create the subpage and contain the headings and subheadings template for the discussion and approval of the actual guideline --Wayne Mackintosh 05:50, 15 July 2009 (UTC)

Hi Jesse, My last question was a sleepy way of saying that I was confused to why the workgroup called Workgroup:style guidelines did not seem to be following the proposed style guidelines. I have added a redirect in Workgroup:Style guidelines to the lower case version, so that I can find the page again when I'm tired. Kruhly 06:27, 16 July 2009 (UTC)

Hehe, yes, I noticed that right after I created the page, then yelled out, "crud!", or something to that effect. Thank you for adding the redirect, though now that you've reminded me, I wonder if it should be moved to the proper title, putting the redirect where it is, now. --Jesse Groppi 16:11, 16 July 2009 (UTC)

Jesse Groppi (talk)‎

Style guide rationale

I figure the rationale should be in the form of an introduction in the header of the charter page. It shouldn't be longer than two paragraphs. What reasoning would you use to justify the use of a style guide? --Jesse Groppi 18:09, 23 July 2009 (UTC)

Jesse Groppi (talk)‎

How to use this space

This conversation was removed from the header because I felt that it was taking away from the readability of the main body of discussions on this talk page.--Jesse Groppi 18:05, 23 July 2009 (UTC)

[Note: I'm not sure where to put this comment: in a new discussion thread, in the talk header or here. I decided here seemed the best option, and have created a little discussion spot. Jesse, I'm fine with using a discussion thread for this kind of feedback if you prefer.]

My vision for the Workgroup namespace is that it is a workspace wherein groups organize themselves. In my vision, the output of the group would rarely be in this space. I think the WikiEducator namespace is a better place for policy and guidelines which impact the entire community. The Workgroup's job is to create and maintain that policy. The Workgroup:WikiEducator_Workgroups is currently collaborating on guidelines to help sort this out.

So, I'm suggesting that this space be used to create a Workgroup charter. One of the outcomes of this workgroup would be a process (collaboratively built based on your proposed process on the talk page) for creating a WikiEducator style guide. That said, one of the key considerations in creating a process for workgroups is that the process facilitates achievement of the desired outcomes rather than undermine it with too much hoop-jumping.

I'd like to hear your thoughts on this. If you agree, we can get started creating the style guidelines charter based on the current charter template. I'm happy to help.

--Alison Snieckus 19:38, 14 July 2009 (UTC)

As for organisation of the pages, I've been talking to Wayne and getting more familiar with your processes at WE. If WE prefers the discussion take place in the WikiEducator namespace, that's just fine, I will move it there. I don't worry about where feedback and comments go, and you may be right that they don't really belong in the same place as the discussion of guideline points, but I want to make sure the discussion of the points take place in only one space, as it's rather confusing and inefficient to allow discussion of the same thing to occur in two different places. I like what Wayne has added to the navigation menu, but I think I would personally change it a bit to be this page, an output/discussion page in the WikiEducator space, and an archive of the discussion to be a subpage of it.

I'm also discussing the workgroup guidelines with Wayne. I'm happy to help test out the ideas of the workgroup, but I think I'm going to insist on straying from them in certain areas. I will be copying over the template shortly, and you may also soon see me lending my voice in the discussion of the workgroup guidelines.

--Jesse Groppi 20:27, 14 July 2009 (UTC)

I don't think we have a decision yet on how to handle where the guidelines will live. Where to keep community-wide policy and guidelines is very much in develop in the WE Workgroups group -- I was just sharing my *current* vision. I look forward to your thoughts on how to organize the workgroup process and outputs; please do lend your voice to the discussion of workgroup guidelines.

I totally agree that for something like collaboratively building a style guide (and maybe for lots of other projects) that the discussion needs to happen all in one place.

--Alison Snieckus 23:34, 14 July 2009 (UTC)

I'm alllllmost finished with the charter. --Jesse Groppi 23:36, 14 July 2009 (UTC)

Done! And reorganised according to suggestions, thus this conversation is moved to here. --Jesse Groppi 00:24, 15 July 2009 (UTC)

Jesse Groppi (talk)‎

Styles and content types

Having style guides for "formal" content is great and the suggestions being put forward are appropriate. However, I put lots of information into WikiEducator that is not formal and not really intended for others although it is public. These are notes to myself, dynamic public content (guidelines for my students' projects), links to interesting information, etc. I also require my students to write collaboratively on group projects in WE.

With the style guides, does this mean that these pages would no longer be appropriate within WE? Does this imply that WE is moving to the Wikipedia model where all content is overseen and coodrinated?

I really hope that it will be possible to accommodate formal and informal content and know which is which. --Valerie Taylor 06:47, 17 July 2009 (UTC)

Vtaylor (talk)‎

Hi Valerie,

These are very important questions we need to resolve.

I would like to see a WikiEducator community that welcomes and supports both "informal" and "formal" content. As founder of the project I would not like to see WE evolve into a model where all content is overseen and coordinated. At the same time I would like to see our project strive towards quality in education. That said, I'm not sure how we can achieve these objectives.

As you point out --- we have an opportunity to find creative solutions to "accommodate formal and informal content and know which is which" and I see this workgroup as the vehicle to tackle these challenges.

Let the discussions begin :-)

Mackiwg (talk)‎

Valerie,

WE is definitely a new species of wiki. It has frequently asked me to take a step back and look at what a wiki is from a different perspective. I think the main difference is the idea that some pages are not welcome to open collaboration (they are closed to public collaboration). I think your students' projects would fall under that classification. It's mentioned here that it may be useful to solidify these classifications, and I'm beginning to think it could actually be a good idea.

Personally, I still believe that pages the author considers private (doesn't want anyone else editing) belong in the user namespace. So I would say notes to yourself should be there. I'm think we need to figure out a way to classify pages as private/closed collaborations, so that groups like your classes can work in relative privacy.

That said, though, I still think a style team should look after the quality of all pages. I do agree that coordinated content would defeat the purpose of this wiki, but I think there are very good reasons for having a style guide; it's in each author's best interests to follow it. I agree with Wayne that we shouldn't force it on WE's contributors, but I really think we need to make it totally clear the importance of following the guide.

In regard to "formal" and "informal" content... I really don't think that classification (should) exist(s). I agree we should welcome the content you label as "informal", but labeling it that way gives me the impression those contributors are just "freeloading". I feel that if someone isn't here to help make the wiki better/more complete, fulfill the mission, and reach the goals, I think he's taking advantage. If he is here for those things, well, following the style guide is one of the ways to do them.

So, we can call it whatever we want, but I'll stick by my guns and say that we need somebody paying attention to these things, and making sure that everyone is aware of them as well.

Jesse Groppi (talk)‎

Hi Jesse,

Yeah -- WE is a unique community in many respects. It's fascinating to compare how policies and procedures evolve among different wiki communities.

The user namespace is the best place for private content (where folk don't want anyone else editing). The downside for newbies is that this requires knowledge of the subpage syntax --- which arguably is a more "advanced" wiki skill than creating a new page in the wiki. I'm sure that if we put our minds to this -- we would find a smart technical solution to tackle the issue -- namely making it very easy for users to distinguish between public and 'private" pages. Perhaps something for our usability project with the NZ Ministry of education to take on board.

Good on you for sticking to your guns on stressing the importance of style guidelines :-). Ultimately -- if educators do not believe or support the ideals of quality education -- they're not true educators and I suspect that they're not going to be well aligned with our community vision and goals.

I think the important message here (which we all seem to agree on) is to make sure that we find ways to welcome and support educators on their road / apprenticeship in becoming active contributors to our vision for widening and increasing access to high quality free content materials.

Cheers

Mackiwg (talk)‎

Thoughts on related issues -- over & above style guide recommendations ......

I'm very pleased to see this organic emergence of a work group looking at style guidelines :-) -- A few additional thoughts:

We may need to develop a concise resource on the rationale for guidelines -- eg promoting consistency etc. Perhaps this should be specified as an outcome in the Charter for the workgroup.
Personally, I feel that style guidelines should be an incentive rather than a disincentive for collaboration --- We need to think carefully about the processes whereby we implement the style guidelines. Sadly, some wiki projects use style guidelines as a mechanism to reprimand newbies for not adhering to agreed process. I would love to see a wiki that tolerates experimentation and learning. Perhaps we need to think about a mechanism whereby primary authors opt into the style guidelines. For example -- a category or template which says "I want to improve my resource by adhering to style guidelines -- help!" rather than a witch hunt for pages that don't meet style guidelines. Basically if an author doesn't physically request style guideline compliance -- the style guide police should leave the page alone.
How do we incorporate the style guidelines with the QAF framework as an incentive?
What training materials, resources do we need to support prospective style experts in our community?

Mackiwg (talk)‎

"We may need to develop a concise resource on the rationale for guidelines -- eg promoting consistency etc. Perhaps this should be specified as an outcome in the Charter for the workgroup."

This sounds like a good idea to me. I do consider the rationale to be somewhat self-evident, so my suggestion is that we keep it short and sweet, if we want it to actually be read.

*"Personally, I feel that style guidelines should be an incentive rather than a disincentive for collaboration --- We need to think carefully about the processes whereby we implement the style guidelines. Sadly, some wiki projects use style guidelines as a mechanism to reprimand newbies for not adhering to agreed process. I would love to see a wiki that tolerates experimentation and learning. Perhaps we need to think about a mechanism whereby primary authors opt into the style guidelines. For example -- a category or template which says "I want to improve my resource by adhering to style guidelines -- help!" rather than a witch hunt for pages that don't meet style guidelines. Basically if an author doesn't physically request style guideline compliance -- the style guide police should leave the page alone."

I'm not sure how the guidelines could be perceived as an incentive, other than for qualification for QAF awards. I do understand what you're saying about the wrist slapping of newbies, and I like your idea of making a tag available to the authors to self-address a need for help in that area. Even more experienced authors aren't going to know the best way to meet some of the guidelines.

I'm also going to be a little revolutionary, and suggest we purposely omit a reader-posted tag, because I think that deters from collaboration, promotes laziness, and creates a negative tone. What I do suggest is that we create an ongoing project that monitors the RC, part of their responsibilities being to look out for the style guidelines. We can add a caveat to the style guidelines that says, "If you aren't going to fix it yourself, leave it be, or add a note to the RC workgroup's talk page, suggesting the article be looked at." RC workgroup members would change anything they thought necessary, and leave a note on the talk page, saying why the change was made, and the author is welcome to discuss it or refuse it. If they refuse it, we can have a tag for the talk page that highlights the diff of the change that was refused.

I think that leaving it as an opt-in thing takes away from the importance of having the guidelines, and we need to account for the level of ignorance due to authors not wanting to take the time to research all the available guidelines and policies, which is totally understandable.

*"How do we incorporate the style guidelines with the QAF framework as an incentive?"

Personally, I think the style guidelines should be part of the requirements of the QAF award, but because of the subjective nature of some of the guidelines, there should have to be some sort of consensus by the award team that the guidelines have been met.

*"What training materials, resources do we need to support prospective style experts in our community?"

Part of the development of the guidelines should include adding them into the tutorials and skills training materials. Perhaps this should also be one of the outcomes in the charter? For the style experts, part of the writing of the guidelines would include examples of proper usage, and we could probably develop lists of proper language choices for guidelines that would need them.

Jesse Groppi (talk)‎

Hi Jesse

I'm not sure how the guidelines could be perceived as an incentive, other than for qualification for QAF awards.

While somewhat abstract, I think we can develop and promote a WE culture of striving for quality as an incentive. That is, when users are ready to take this step, rather than policing poor "quality" because, for instance, ESL users may not have the language skills to adhere to our language conventions or may not have the technical skills to implement more sophisticated wiki syntax.

I'm also going to be a little revolutionary, and suggest we purposely omit a reader-posted tag, because I think that deters from collaboration, promotes laziness, and creates a negative tone.

I see your point regarding the risks associated with laziness or detering collaboration. Just checking here -- -I don't see this as a "reader-posted" tag but rather a primary author request to move to the next level of improving quality by adhering to style guidelines. Ideally -- this should be a process where authors can opt into improving their work by adhering to style guidelines. I think its better to have a scenario where WikiEducators can ask -- "How can I get my resource to look so good/impressive?" rather than "I'm embarrassed because the style-guideline police are doing a bunch of stuff on my page which I don't know how to implement". Style-guideline gurus could be pro-active and post invitations to assist with improving pages -- but we should allow freedom for users to do their own thing until they are ready for the next level. This is more of a process and implementation issue rather than the detail of the guidelines themselves. Clearly we will need to separate the process from the content of the guidelines as such.

We'll have enough work with folk opting to improvre the quality of their resources --- but I think we need to wait until they're ready for the ride :-)

Personally I don't see the opt-in scenario as taking away the importance of guidelines --- Educator's by nature want to do the right thing. Half our users are over 45 years old and are taking personal "risks", in most cases, publishing to the Internet for the first time in their lives. Having a stranger redirect or moving a page because it doesn't adhere to a style convention for naming pages can be a daunting experience -- particularly when you don't have the requisite wiki skills to understand how this works :-)

I think we need to be smarter than WP and figure out creative solutions regarding how we can deal with this challenge. The OER Foundation is committed to sourcing the funding we may need to implement technical solutions to achieve this aim.

If we do a good job, with corresponding tutorials training etc --- we'll promote the implementation of good style -- prevention is better than cure :-)

Personally, I think the style guidelines should be part of the requirements of the QAF award, but because of the subjective nature of some of the guidelines, there should have to be some sort of consensus by the award team that the guidelines have been met.

Yeah -- it seems that we would need to categorise the guidelines between "objective" & "subjective" guidelines. For example, the guideline on capitalisation for new pages is reasonably objective, whereas a guideline relating to proposed structure for hierarchy may vary according to subject discipline or preferred pedagogical approach. We'll need to think carefully about how we incorporate these requirements into the QAF.

Part of the development of the guidelines should include adding them into the tutorials and skills training materials. Perhaps this should also be one of the outcomes in the charter?

Agreed -- I think this should be specified as one of the outcomes in the charter.

Mackiwg (talk)‎

I'm totally agreeing with what you say. What if we come up with a way our "gurus" can point out potential issues to authors?

Jesse Groppi (talk)‎

Yeah --

I think we can come up with a smart way for our gurus to point out and help with potential issues -- eg templates that include links to resources and online training opportunities to improve style guide compliance.

This is coming together rather nicely :-)

Mackiwg (talk)‎

A thought has occurred to me about applying style guidelines to WE pages. I think that we could divide WE pages into three types:

1. Core pages - pages which are part of WE proper - in other words not OER - for example, main page, tutorials and help pages, or workgoups. I would also apply this to some items such as page names or categories, which would affect the site as a whole.

2. Sponsored pages - I am using the word sponsor loosely, meaning associated with a specific school, project, or organization. My reason for considering these separate is that there may be conflicts between WE guidelines and those of the sponsoring group (for example, a country's QF), therefore some flexibility may be required.

3. OER's not in type 2, where more of Wayne's "experimentation and learning" could be done. These may allow opt-out's in whole or in part.

JohnWS 10:05, 17 July 2009 (UTC)

JohnWS (talk)‎

Hi John,

That's a useful classification framework :-) --Appreciate your contribution!

I think were dealing with at least two (possibly more) classification axis on the graph so to speak:

Type of WE resource/page -- eg OER (lesson, handout, learning activity etc), project node (eg Country page, research collaboration or sponsored pages etc.)
Maturity level of user --- eg 1) Beginner struggling with with wiki syntax 2) Early adopter developing a teaching resource for personal use 3) Mature WE seeking collaboration and community kudos

It seems to me that there are generic and objective guidelines like capitalisation on page new page names that could be applied across the wiki, spelling etc. - irrespective of the type of resource. Punctuation and preferred citation format would also fall into this category. That said do we create a guideline on spelling --- "American English" versus "UK English" etc. Perhaps we accommodate both?

The issue is do we "punish" a beginner for not adhering to objective style conventions by "intruding" on their space in the wiki or do we encourage the wider WikiEducator community to jump in an help out with "objective" style conventions?

There will also be more subjective style conventions, for example hierarchy of learning resources and sub-page structuring etc.

These are exciting times -- were pioneering new futures. A wiki dedicated to educational resources and supporting projects is an order of magnitude more complex than figuring out style guidelines for an encyclopaedia article :-)

Cheers

Mackiwg (talk)‎

Wayne,

I agree with what you are saying about beginners. I do not think that WE should be aggressive and "punish" beginners or do anything else that causes people to leave WE. Indeed guidelines are just that guidelines - we do not won't a "style police". On the other hand beginner's can use the guideline as "guidance" if they are unsure about an issue. What we need is flexibility.

Cheers.

JohnWS 11:47, 17 July 2009 (UTC)

JohnWS (talk)‎

Well said :-)

What we need is flexibility --- now the challenge is to encapsulate this into our process documentation.

Cheers

Mackiwg (talk)‎

Wayne,

I'm not sure we should classify by the knowledge/experience level of a user. I think this is too much of a grey continuum, and I'm not sure I would find it empowering, as a new user of WE, so much as a big rubber stamp on my forehead that says, "DOESN'T KNOW WHAT SHE'S DOING". There's really no way we can tell what the maturity level of the user is. He may be an expert at some things, but not do well at others. She may be brand new to WE, but know how to run MediaWiki with nothing but MySQL and php code. I've run my own MW wiki, but there's no WikiArtisan tag on my user page. Do you see what I mean?

I think we should wait to decide what to do with guidelines that don't or only apply to a certain classification until after we've proposed one. I think that's a sort of beast I couldn't predict, but I do think it's possible. I think we can lay the groundwork for it, but working on classifying the basic types of work done here (see my reply to john), and that should be sufficient, otherwise we may be in danger of putting boxes around 3 year olds.

Jesse Groppi (talk)‎

Hi Jesse,

That's a valid point and excellent example :-) This also alludes to a gap we have in the WikiMaster certification typology -- namely a "Recognition of Prior Learning" (RPL) mechanism for new folk joining WE who want to opt in for the community certification typology ;-).

Extending the example - -just for illustration purposes -- we do not know how you feel about WikiArtisan certifications on your user page -- until such time as the user say's --- Yes, I would like to have my skill level "recognised" by a tag on my user page.

I do agree -- we can't decide what to do with guidelines until we've proposed them and thought about their application and implementation.

I sense that we're all on the same page here with regards to respect for individuals and the diversity of their experience. I sense a high level of consensus in that WE should continue to be a welcoming and supportive environment for newbies finding their way with the "complexities" of wiki technology and challenges of developing educational materials.

Lets continue and figure out the best ways to develop and implement style guides for our community :-)

Mackiwg (talk)‎

John,

Core pages: These are pages that are not in the main or user namespace, and at the moment, I can't really think of any instance in which they require more, less or different guidelines.

Sponsored pages and otherwise: I'm not sure this is the way I would want to classify the different sorts of projects going on. If you look at the "Style and content types" conversation on this page, you'll see that I'm thinking of classifications more along the lines of "solo", "private collaboration", and "open collaboration". Private collaboration would be the sorts of things you describe as "sponsored", and then I break down the rest even more into work the author doesn't want any help with, and work the author(s) want everyone's help with.

Now, solo work, and I really don't think I'll change my mind on this, belongs in a subpage of the author's user page. The namespace already holds the meaning that nobody should touch it but the guy whose name is on it. Why not use the assumption as an advantage, instead of other tedious methods of designating the work as solo? The work can still be categorised, and there are lots of tools to deal with the cumbersome titles.

It was that idea that led me to think that we can use other namespaces for the very same advantage. The main namespace already very clearly and traditionally says, "everyone's", so that fulfills the needs of that sort of classification. But, we don't have an "ours" namespace, so I think we should make one. I'm not coming up with any good names for it... any ideas?

Jesse Groppi (talk)‎

Sarcasm or humour?

Is the opening sentence at Workgroup:style guidelines#Skills required to achieve workgroup objectives sarcastic? I was trying to be humourous. --Jesse Groppi 00:32, 15 July 2009 (UTC)

Jesse Groppi (talk)‎

I read it as humour, definitely. But if you want to encourage the humorous interpretation, you could add <smile> at the end.

I also suggest rewording the part about needing to be fluent in English: "...read and write in fluent English...". I don't think this is a requirement for every person. A person with less than fluent English can certainly contribute, and we want to encourage them to do so. There are plenty of us native English speakers around to edit the wording as needed.

--Alison Snieckus 01:47, 15 July 2009 (UTC)

ASnieckus (talk)‎

I suppose the definition of "fluent" is rather arguable. I generally assume if you're able to contribute in English, regardless of how good, you're fluent enough for me. :P I put it in there as a silly, superfluous requirement, but you're right that it may be taken as a reason not to participate by someone that doesn't consider herself "fluent". Thanks for pointing that out!

Jesse Groppi (talk)‎

General format for guidelines

My suggestion would be:

==== Short phrase describing the guideline ====

Detailed description of the guideline.
*Any examples

Simple instructions for the implementation of the guideline.

Jesse Groppi (talk)‎

Retrieved from "https://wikieducator.org/index.php?title=Talk:Workgroup:style_guidelines&oldid=405059#General_format_for_guidelines_10328"