Inkipedia:Proposals/Sandbox Policy Revision

Additional section to the Inkipedia:Policy/Sandbox:

Expected lifetime of sandboxes
Sandboxes may have an unlimited lifespan. However, due to drafts being inherently useful to the wiki, they should be merged into the mainspace within good time. Sandboxes that test code or functionality, once testing is completed, should be marked for deletion.

If a sandbox has outlived its usefulness, for example but not limited to:
 * The quality of the draft sandbox is good enough for mainspace
 * The sandbox's contents have already been merged into mainspace
 * The functionality it is testing is complete
 * The page is completely broken

Then the following procedure should be adhered to:
 * The editor who is not the sandbox owner should contact the sandbox owner via their talkpage. For known-active editors, Inkipedia:Discord may also be used.
 * If the sandbox owner responds and agrees, then the sandbox should be moved by the owner (or an administrator if the owner does not have permission to do so), or deleted/marked for deletion as appropriate.
 * If the owner responds and disagrees, then no action is taken. Further discussion among editors on the sandbox talk and/or owner's talk is encouraged.
 * If after 7 days the owner has not responded, then the requester may move the sandbox into mainspace or mark for deletion as appropriate, or ask an administrator to do so.

Exceptions to this policy may be granted by an administrator, if that administrator is not the requesting editor or sandbox owner.

Start date: 2023-12-16

End date: 2024-01-06

Support

 * 1) Sound addition that addresses the gaps in the current policy. Yoshifan52 (talk) 21:06, 16 December 2023 (UTC)
 * 2) I don't have a reason to oppose this, it is a logical proposal.  15:41, 18 December 2023 (UTC)
 * 3) Excellent proposal that balances the needs of individuals and the needs of the wiki as a whole. I especially like how this provides a clear rule for dealing with useful drafts from non-responsive authors, a rare occurence but certainly something the wiki would be better prepared to deal with should this proposal pass. Heddy (talk) 21:36, 20 December 2023 (UTC)
 * 4) Per the others, good stuff to clarify the existing policy. GloverMist (talk) 11:48, 22 December 2023 (UTC)

Oppose

 * 1) I don't believe we should be taking away work from people, even under extended periods of time. If content needs to be integrated into main pages, copy it over with link reference in edit summary or create a copy in a new user draft. Sandboxes inherently are a user's personal testing ground and that private space shouldn't be infringed. Sandboxes are also one of a few times where a blank page is likely acceptable as not every user may need to test something constantly at all times. I sure don't. It creates more hassle for both users and staff to create and delete repeatedly when a need arises. It also has potential to remove content and delete revisionist history. To me, this seems to discourage the creation of sandboxes altogether because the value of the pages you make, possibly in learning, aren't going to be respected. If this passes, I'll probably be moving a lot of the stuff thay I have up to a different platform because of this potential deletion. The sole exception to this policy I would suggest keeping is entirely broken pages are commented out. Trig - 13:40, 23 December 2023 (UTC)
 * 2) Since this proposal was submitted something's been bothering me about it that I couldn't put my finger on, and I feel Trig has summed it up rather well. I think the idea behind this revision is broadly well-intentioned but ultimately will do more harm than good if codified as policy. Driftin Soul (talk) 15:04, 23 December 2023 (UTC)
 * 3) Generally the same reasons Trig has stated above. Unless it's broken to the point where it's affecting other pages, I don't believe user pages should be touched without permission from the owner. I especially find 7 days too small of a window to expect a response for such a big change.  15:21, 23 December 2023 (UTC)
 * 4) I think it is good to contact editors if the contents of their sandbox are ready to be added mainspace. However, I don't think it should be possible for sandboxes to be moved or deleted without the editor's permission. If there is something which is causing disruption/ is broken, then I think that only that part should be removed. If the sandbox contains something that would be useful for mainspace, and the editor who made the sandbox does not respond, I would prefer that it is copied without altering/moving the original sandbox.   23:33, 23 December 2023 (UTC)

Discussion
What is this even about? I can't understand a thing that was said.
 * In short, how should Inkipedia treat user sandboxes that are not edited over a period of time. I would say that if the wording is causing confusion, that would be an issue with the proposal itself to take into consideration. Trig - 15:27, 23 December 2023 (UTC)


 * Moved discussion in reply to Trig's post:
 * I'd like to hear more on your stance. We're not taking edits away from users, if anything, it avoids the copy-paste of content from userspace into the mainspace and maintains the history of edits the initial user has done. Also, why would we copy the content into a new user draft? Now we have two userspace drafts and that's double the problem. The amendment specifically calls out working together in cases where the author does not feel like the content is ready to be merged, and under those circumstances, I'd recommend the two users working together on the draft page.
 * Further, this addition fits in nicely with the UCT policy where we are minimising outstanding user pages.
 * That all being said, I wouldn't be looking to delete user's sandboxes on a regular basis, despite what this policy section may imply, even if they are blank pages. This policy amendment focuses around multiple user pages (drafts and sandboxes) being abandoned but salvageable. Do you feel that needs to be made clearer in the proposal? 14:38, 23 December 2023 (UTC)
 * "The quality of the draft sandbox is good enough for mainspace"—Who decides that? The author? Administration? What if there is a major feature that still plans to be written and has not been added yet, but the author still plans to? "The sandbox's contents have already been merged into mainspace" — Like mentioned prior, this is useful for edit history should be preserved in this way. "The functionality it is testing is complete" — I test a lot of things and leave it up for later reference. It seems counter-intuitive to take this reference away for myself or other people who may frequently use their sandbox to understand certain mechanics. If you're learning about say switch parser functions and you have a working example in a sandbox that is familiar to you, why would it need to be deleted? "The page is completely broken" — Pages rot, that's the nature of things. Major issues should be commented out if truly deemed necessary, like I have done with a few of Guy's sandboxes in the past.
 * This proposal has nothing to do with the User Content Policy. That was explicitly to reduce the amount of non-constructive, off-topic content being housed on Inkipedia such as fan art, theories, and fanfiction. Constructive pages (like sandboxes and drafts) were specifically excluded from said policy because they serve a greater use function both for pages being developed but also helping users learn the ins and outs of the MediaWiki system. I feel as though this only punishes said attempts to learn because once you're done testing something well we just have to delete all of that progress because...well, because there's a policy saying you need to, I guess. There's no need to remove this content especially when it is constructive in nature. I think where this actually stems down from is that there were a few page drafts that were considered decent and someone wanted to move them to the mainspace. This can easily be handled on a case by casis, and in the event that they do not respond, you can copy over content with a link for appropriate attribution.
 * I also think this doesn't take into account time very well. Many people get caught up with real life, such as school, work, vacation, or illness. Maybe there was a major death in the family and they need to step away for a month. Are you going to take their work in progress and put it, incompletely, into a mainspace page before they were ready to do something with it and weren't able to respond to the inquiry? It just feels like there is more value placed in the words on the page over the people writing them. Content will be completed when it is complete. If development of something else isn't moving how fast you want it to, I honestly suggest making your own version instead or trying to collaborate. Trig - 15:25, 23 December 2023 (UTC)


 * "Who decides that?" That is decided by the person asking the author for permission to move it. If the author still has plans, then they can respond to the request, or, move it and work on it in mainspace if it's gotten to a point of being good enough for mainspace.
 * "The sandbox's contents have already been merged into mainspace" This happens when a dedicated sandbox page is created, then its contents are cherry picked into mainspace, probably by the sandbox owner. Then, it's just a duplicate page in usersapce.
 * "I test a lot of things and leave it up for later reference." Then it has not outlived its usefulness and can be kept as a reference page.
 * "Major issues should be commented out if truly deemed necessary" Major issues should be fixed or commented out, yes. I'd concede this point in the proposal to be removed.
 * "I also think this doesn't take into account time very well." Cool, that's a separate point. I put 7 days here because that ties up with other notifying policies that we have. I'm happy to discuss this, but this arbitrary time is essentially solving a Halting problem to make use of an abandoned draft.
 * "I honestly suggest making your own version" Then are you suggesting copy-pasting with a link in the change? Or are you saying start from scratch? If we want to go down the route of copy-pasting with a link back then I feel like that's disingenuous to the original author, especially if they're actively working on the draft.
 * 16:07, 23 December 2023 (UTC)

I think the policy would be better if all parts about deleting were removed. The rest of the policy seems to be on the right track. Inkipedia is supposed to be collaborative. Collaborating happens best on mainspace. Personal drafts are restrictive, as people have to ask the author for permission to contribute, per Inkipedia policy. So, with time, we should be asking users if they are ready to move their draft to mainspace. Articles don't have to be 100% complete to be ready for mainspace; if the authors believe their draft is ready to be improved by the broader community, then it's time to move.

If someone writes part of an article in their user space and abandons the wiki, what do we do about the article? Leaving a talk message is definitely the right answer. And if they say they don't want it in mainspace yet, then great, we don't need to do anything. But what if there's no response? The CC-BY-SA license that everyone implicitly agrees to by contributing to this wiki allows anyone to freely copy and modify any text submitted to this wiki, so without a policy to define and restrict our behavior, we have the right to do whatever we want with their unfinished article. So we definitely need a policy to define our behavior here, and to create that policy we need to know what this community feels is a fair and respectful way to handle this. Do we declare that no one shall ever use that content without the original author's permission? That would seem to be against the spirit of the Creative Commons license, and against the spirit of a wiki that is collaboratively edited and therefore has authors, but not owners. Do we copy/paste out some useful parts, without moving the original draft? Do we wait until someone "adopts" the article? Do we wait a certain number of days? Slate's answer was to wait 7 days of no response before moving. I'm fine with that. To anyone who's not fine with that, what exactly do you suggest? Heddy (talk) 16:31, 24 December 2023 (UTC)