You can simply leave a warning on sandboxes and drafts, or a "NOINDEX" 
template. And rejected content can also stay there, it just can't go to ns0 at 
least for a while. I mean if I open a sandbox or draft, write a description of 
something below notability in many cases it's not erased and/or noticed. It 
just stays there. So why a content deleted from ns0 is so different? Of course 
than every platform has its own rules  but there's a clearly difference between 
an Afd of a dust-covered sandbox or draft and a freshly edited article. I mean 
the number of deleted articles are the same in the end, it's just less 
controversial.
You can just take all the very old unused non-ns0 content pages and revise 
after few years. There's stuff you can actually use after a while. Most of the 
time that person has become important "enough" to have an ns0 entry, the local 
factory is still open and can be inserted in the paragraph about economy of a 
village, a new article has appeared on wikivoyage where the description a shop 
can be cited, the image locally uploaded by a newbie can be transferred to 
commons, the poor description of an actor or athlete or researcher has enough 
IDs to crate an item on wikidata, the description of a building can be put in a 
table in the new article about the street or neighborhood where the building is 
located. And so on. Sometimes the original owner has forgot about it so you can 
work with calm at this revision. 
It's mainly a lack of management, IMHO, that forces people to go keep/delete in 
a rigid way. We waste there more stuff than necessary while we need maybe just 
a good retropatrolling. 
 

    Il Mercoledì 12 Ottobre 2016 12:51, Anders Wennersten 
<m...@anderswennersten.se> ha scritto:
 

 One (unrealistic?) brainchild of me is that Wikipedia should be have as 
a key element, a reliability class set on all articles, say A-F, where 
today's articles would mainly be C (no issues) and D (issues exist). 
That articles with a A or B class would require only Trusted user 
account to edit, and E and F would be new set of articles not qualified 
for Wikipedia. And it would require special setting to access E or F 
articles and they would be seen with another Logo then Wikipedia and 
perhaps a red warning dimmingsceen

Anders

016-10-12 kl. 12:22, skrev Peter Southwood:
> I agree.
> There is a lot of information that could be provided for and by people who 
> are interested in trivia (I am not using the term derogatively - just 
> couldn’t think of a better one).
> Cheers,
> P
>
> -----Original Message-----
> From: Wikimedia-l [mailto:wikimedia-l-boun...@lists.wikimedia.org] On Behalf 
> Of Alessandro Marchetti
> Sent: Wednesday, 12 October 2016 11:40 AM
> To: Wikimedia Mailing List
> Subject: Re: [Wikimedia-l] A new Wikipedia fork: InfoGalactic
>
> I agree with Anders. About the issue of weak/bad/irrelevant/border-line 
> content management. I don't care about that specific project although I do 
> support plurality in any case.
> But "not wasting" material and HRs is a key issue. For all platforms. At the 
> moment I would strongly encourage at least to use all the "tools" we have 
> already at their maximum potential, which we are not doing. These include:
> 1) a better knowledge of all wiki platforms and how they work.Try to avoid 
> that paternalism that some wikipeda users show off when they decide a priori 
> something is not even worth transferring. It's quite snob. We have many 
> projects and sometimes transferring content is not so difficult. Even if you 
> delete pokemon articles a book about pokemons on wikibooks is still a good 
> thing to have. And that recipe in a food article maybe deserves more than 
> just be cut off.
> 2) support an extensive use of draft space and a correct management of all 
> drafts. And a bigger tolerance for draft spaces in general. Don't stress 
> people on that, there are always better things to do than "harassing" people 
> about stuff in sandboxes and drafts. Next time you want to do something like 
> that, don't and work on the main namespace. And see yourself if things are in 
> the end better or worse globally. Some of these problems just require time. 
> You wait and sources arrive.
> 3) a better information sharing with the projects. This always annoys me, 
> these long-term wiki users that rarely inform any project or usually the lest 
> competent one about an Afd or a warning. And when you do inform people around 
> and you show that other users disagree with a rigid deletion procedure and 
> they're willing to help or similar they never thank you, and never learn. 
> They play their little game and they have never understood after years that 
> wiki is about sharing knowledge. Not about deleting a content as fast as 
> possible because "I know how the world works". No, you DON'T. Sometimes these 
> rigid deletionists are pushing for the road that allows a fast deletion per 
> se, not because this makes the life of editors simpler. I'm convinced because 
> fo that we pay a price as a community that is much bigger than the 
> "embarrassment" of leaving on the main namespace for few days or weeks an 
> improper article that most of the time almost noone visits. I did many lists 
> of all articles that needed revision (unedited by human users in years, for 
> example) and in every platform there's always plenty of stuff that was much 
> more critical and people missed for years, including hoaxes. Because they 
> were spending too much time copy-pasting the same links or comments in order 
> to delete the article of the last minor actor or mid-sized company whose 
> presence doesn't really make any difference in the perception of our overall 
> quality.
> 4) efficient article connectivity. Make article-lists for example. Encourage 
> to group content with a rationale. You can prevent a lot of useless "spin 
> off" in many cases.
> If you start to apply this good practices,  you can reduce the number of 
> critical cases (and "social" consequences) by a double digit. Only at that 
> point I would ask for additional solutions. Because If after so many years we 
> can't even do that, I think we still have better things than worrying or 
> making fun about forks.
>
>  
>
>      Il Mercoledì 12 Ottobre 2016 10:31, Peter Southwood 
><peter.southw...@telkomsa.net> ha scritto:
>  
>
>  Wikitrivia?
> Cheers,
> P
>
> -----Original Message-----
> From: Wikimedia-l [mailto:wikimedia-l-boun...@lists.wikimedia.org] On Behalf 
> Of Anders Wennersten
> Sent: Tuesday, 11 October 2016 12:16 PM
> To: wikimedia-l@lists.wikimedia.org
> Subject: Re: [Wikimedia-l] A new Wikipedia fork: InfoGalactic
>
> I think this initiative point to a weakness in our approach, that is worth 
> discussing, independent if just this will be anything or not.
>
> In our version we have somewhat lower quality demand then enwp, and we can 
> also be more pragmatic and handle cases individually, but still one of our 
> most recurrent discussion is on how we handle articles that is too 
> weak/bad/irrelevant to be allowed into our articlespace but still not are 
> rubbish. We have looked into 1)enwp alteranative with a draft space, 2) to 
> have special signals to engage editor willing to work on these, 3) to give it 
> back to the user who put it into Wikipedia with text explaining what is the 
> problem, 4) different type of templates, 5)and have special pages where these 
> can be discussed.
>
> Some of these (and pragmatism and good mentors) help a little bit, but does 
> not solve the basic issue, that users create articles (not being
> rubbish) that is not allowed into our article space, which makes them very 
> disappointed (angry)
>
> Anders
>
> Den 2016-10-11 kl. 11:58, skrev Peter Southwood:
>> Competition is healthy, it can be useful to test alternatives and separate 
>> out the ones that work from the ones that don’t. However I think Starlords 
>> may be one that doesn’t work and may bring down the project prematurely. I 
>> will watch in case they develop anything actually useful - who knows...
>> Cheers,
>> Peter
>>
>> -----Original Message-----
>> From: Wikimedia-l [mailto:wikimedia-l-boun...@lists.wikimedia.org] On
>> Behalf Of Craig Franklin
>> Sent: Tuesday, 11 October 2016 8:48 AM
>> To: Wikimedia Mailing List
>> Subject: Re: [Wikimedia-l] A new Wikipedia fork: InfoGalactic
>>
>> So what you're saying is, Vox Day has created a "safe space" where his 
>> circle of friends can reinforce each other's biases without interference 
>> from the outside world?  Great.
>>
>> Also, "Starlords".  Good grief.
>>
>> Cheers,
>> Craig
>>
>> On 11 October 2016 at 04:13, David Gerard <dger...@gmail.com> wrote:
>>
>>> "INFOGALACTIC: an online encyclopedia without bias or thought police"
>>>
>>> Home page: http://infogalactic.com/info/Main_Page
>>> Announcement: http://voxday.blogspot.com/2016/10/project-big-fork-
>>> infogalactic.html
>>> Roadmap: http://infogalactic.com/info/Infogalactic:Roadmap
>>>
>>>
>>> - d.
>>>
>>> _______________________________________________
>>> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
>>> wiki/Mailing_lists/Guidelines New messages to:
>>> Wikimedia-l@lists.wikimedia.org
>>> Unsubscribe:
>>> https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>>> <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
>> _______________________________________________
>> Wikimedia-l mailing list, guidelines at:
>> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
>> New messages to: Wikimedia-l@lists.wikimedia.org
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>> <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2016.0.7797 / Virus Database: 4656/13187 - Release Date:
>> 10/10/16
>>
>>
>> _______________________________________________
>> Wikimedia-l mailing list, guidelines at:
>> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
>> New messages to: Wikimedia-l@lists.wikimedia.org
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>> <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: 
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
> <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2016.0.7797 / Virus Database: 4656/13187 - Release Date: 10/10/16
>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: 
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
> <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
>
>    
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: 
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
> <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2016.0.7797 / Virus Database: 4656/13193 - Release Date: 10/12/16
>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: 
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
> <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>



_______________________________________________
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

   
_______________________________________________
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Reply via email to