Return to article

Proposal talk:Userspace policy

Revision as of 22:49, 7 December 2012 by Kerry Raymond (talk | contribs) (mostly about proposals)
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Feedback

I don't know a lot about the policies here, but this does look like an improvement. --Chris Watkins 16:15, 1 December 2012 (EST)

It seems excessive to say that all currently financial members contributing to the page need to agree before a page can be deleted. An admin may need to make the call to delete despite disagreements. Angela 23:11, 1 December 2012 (EST)

If we dont require agreement, could we require all users are notified before the deletion happens and are given time to object? John Vandenberg 10:09, 2 December 2012 (EST)

I'm in agreement with Angela here. Otherwise there's the risk that someone could use the page to harass someone and then use that very contribution to block its removal. Andrew Owens 02:55, 3 December 2012 (EST)

I agree with Angela. Tony1 20:30, 3 December 2012 (EST)
I agree also there must be descreationary options for sysop/committee members to delete a page without notice or agreement of those that created or editted it, otherwise WMAU could be seen as facilitating a whole vegie garden of nasty beans. Gnangarra 22:54, 3 December 2012 (EST)
I agree that some content warrants immediate take-down. But I presume we can hang onto the content in case any of the contributors request it for some other purpose. Kerry Raymond 08:59, 8 December 2012 (EST)

Template on all user pages

I believe a template "should" be on user pages where there might be a problem asserting "ownership", not "must".

If it is going to be "must", we should use the technology to enforce it. Mark Hurd 12:10, 2 December 2012 (EST)

I would prefer 'must', but 'should' is OK.
I think it is easy to manually add a template to everything under special:allpages/User:. (I see now we'll need to add an exception for .css and .js)
We could use mw:Extension:HeadersFooters, or the more flexible mw:Extension:HeaderFooter if we fix it to work with the latest mediawiki. However, I would expect that we will want to use different templates for each type of userpage. e.g. reports would contain one type of header template; proposals would use {{proposal}} (I've changed this template accordingly); personal statements like User:Lankiveil/2012 Board of Trustees statement and User:John Vandenberg/Marriage announcement would have a different one. John Vandenberg 13:20, 2 December 2012 (EST)

topic limitations

I think it should also have a limitation on the what the page is about, there probably a few more things that cna be added Gnangarra 23:02, 3 December 2012 (EST)

  1. related to WMAU activities, or other activities that fit within our Statement of Purpose
  2. No Advertising,
    Self promotion, personal bio pages ok
    No deals, offers or competition notices or prize give aways etc anything that is clearly commercial in nature
  3. No extremely offensive materials, or links to such.
  4. No copyrighted works


Yes to all of those, and if we ever introduce a Code of Conduct, anything in violation of that. Kerry Raymond 09:00, 8 December 2012 (EST)

User pages and Proposals

I would suggest splitting this proposal into two:

  • one dealing with user pages
  • one dealing with Proposals (which I don't think belong on user pages as nobody will see them there)

I think proposals have a lifecycle with associated status:

  • Draft1, a draft created by one member(Draft1), may be altered only by that member (or by "friendly amendment" -- i.e. proposer permits another to make changes)
  • Draft2, a draft which now has support of second person, may be altered only by creating member (or by friendly amendment)
  • Final, a proposal created and seconded and submitted to the committee for decision, may not be edited by anyone
  • In Progress, a proposal agreed to by the committee, proposer can initiate actions to "make it so"
  • Unsuccessful, a proposal rejected by the committee
  • Draft2 (again), a proposal which the committee feels is currently incomplete for the purposes of making a decision and is returned with feedback on additional information required
  • Inactive, a successful proposal that appears not to be progressing but is still approved by the committee
  • Abandoned, a successful proposal that has not proceeded for some reason and committee in consultation with the proposer believe cannot be resurrected (e.g. may have been overtaken by events), allows committed but unspent funding to be released
  • Completed, a successful proposal that has been implemented, allows committed but unspent funding to be released

If the proposals page was organised by status, it would be easy to move proposals around so people knew what was the status of all proposals. Proposals can be moved to the Archive pages if the committee decides that they have had no activity in X months and can include proposals with status Draft1, Draft2, Unsuccessful, Abandoned, Completed. At the request of a member, the committee may agree to restore the proposal to the main proposals page.

Finals are never archived (as they must go to committee decision which will result in a Draft2/In Progress/Unsuccessful). In Progress and Inactive are never archived (they must first transition to Abandoned/Completed).

By introducing a proposal lifecycle, we can have:

  • clear criteria on transition between the different status
  • precise administrative processes that facilitate that transition
  • terminate projects because they have succeeded or failed, allowing unspent funding to be released
  • precise rules for de-cluttering the proposals page

And one final thing. Proposals should be linked off the sidebar on the Wiki. Kerry Raymond 09:49, 8 December 2012 (EST)