[openstack-dev] [wiki] How to delete an unused page in OpenStack wiki?

[Chen Ying]

hi,

Does anyone know how to delete an unused page in OpenStack wiki?
This page[1] is needless. But I can not find an option to delete it.



   [1]   https://wiki.openstack.org/wiki/smaug




Best regards.

Chen Ying
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Wiki upgrade maintenance 21:00 UTC Friday, August 12

[Jeremy Stanley]

On Friday, August 12, from approximately 21:00 to 23:00 UTC our
Mediawiki instance on wiki.openstack.org will be upgraded from its
present 1.25 pre-release to the latest 1.27 version. We're allotting
two hours in case issues are encountered with the upgrade requiring
us to roll back to a snapshot, but if all goes well the outage will
hopefully be much shorter.

JP Maxwell, who has worked through the upgrade plan over recent
weeks, set up a test instance for us at
https://wiki-upgrade-test.openstack.org/ where interested parties
can perform some preliminary tests over the next couple days and
help us catch any important features/extensions which are broken or
missing. Note this is running from a snapshot of the production
database, so will not reflect content changed at wiki.openstack.org.

Feel free to catch us in #openstack-infra or follow up to this
message if you have any concerns or want additional information on
this maintenance.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Anita Kuno]

On 05/11/2016 02:06 PM, Paul Belanger wrote:
> On Wed, May 11, 2016 at 05:51:41PM +, Jeremy Stanley wrote:
>> On 2016-05-11 10:04:26 -0400 (-0400), Sean Dague wrote:
>> [...]
>>> Before deciding that it's unsurmountable, maybe giving delete
>>> permissions to a larger set of contributors might be a good idea.
>> [...]
>>
>> I have no objection to granting delete (on non-locked articles) to
>> all users immediately if someone works out the necessary
>> configuration change to put that into effect. I expect it was
>> restricted by default to encourage people to instead annotate
>> articles as deprecated or use the "move" feature to redirect them to
>> more relevant ones. That said, I think we're at the point where we
>> should start considering such important content as candidates to
>> move elsewhere outside the wiki (especially any currently remaining
>> locked articles).
>>
>>> I do realize running a public wiki is a PITA, especially at the
>>> target level of openstack.org.
>> [...]
>>
>> The thing which would most significantly reduce its attractiveness
>> to spammers would be to stop having major search engines index the
>> content on it. Somewhere they can publish content and have it
>> immediately show up in search engine results is really _all_ they
>> care about. Maybe a compromise is to say that the wiki is an okay
>> place to publish things you don't need people to find through
>> external search engines? Then we could quite easily open account
>> creation back up with minimal risk and much lower moderator demand.
> 
> I think giving out delete permissions is a good first step, however if we are
> going down this path of keep the wiki alive, I believe we have to look at
> re-evaluating mediawiki.

Our current plan includes keeping the wiki maintained for a least a year
in any case, for some definition of maintained. On the etherpad for the
session, Craige had made notes of wikis other than mediawiki that he
liked. The group that was in the session decided not to pursue an
investigation of these suggestions but should any party feel interested
in investigating and creating a comparison, the suggestions still exist
in the session etherpad.

Thanks,
Anita.

>   Our current setup with puppet is not idea and I feel
> mediawiki is maybe too much software for what we are doing.
> 
> I'd love to use something more easier to manage (ideally not php based).
> 
>> -- 
>> Jeremy Stanley
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Jeremy Stanley]

On 2016-05-11 14:01:37 -0400 (-0400), Sean Dague wrote:
> Well, part of the reason for the wiki over etherpads is that it is
> findable in google.
[...]

Yep, also if we somehow found a way to get them to index our
etherpads, those would be overrun with spam in short order. This was
the case with the paste server too, and as soon as we added a
robots.txt to get search engines to cease indexing them the abuse
situation we had there trailed off to nothing in a matter of weeks.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Paul Belanger]

On Wed, May 11, 2016 at 05:51:41PM +, Jeremy Stanley wrote:
> On 2016-05-11 10:04:26 -0400 (-0400), Sean Dague wrote:
> [...]
> > Before deciding that it's unsurmountable, maybe giving delete
> > permissions to a larger set of contributors might be a good idea.
> [...]
> 
> I have no objection to granting delete (on non-locked articles) to
> all users immediately if someone works out the necessary
> configuration change to put that into effect. I expect it was
> restricted by default to encourage people to instead annotate
> articles as deprecated or use the "move" feature to redirect them to
> more relevant ones. That said, I think we're at the point where we
> should start considering such important content as candidates to
> move elsewhere outside the wiki (especially any currently remaining
> locked articles).
> 
> > I do realize running a public wiki is a PITA, especially at the
> > target level of openstack.org.
> [...]
> 
> The thing which would most significantly reduce its attractiveness
> to spammers would be to stop having major search engines index the
> content on it. Somewhere they can publish content and have it
> immediately show up in search engine results is really _all_ they
> care about. Maybe a compromise is to say that the wiki is an okay
> place to publish things you don't need people to find through
> external search engines? Then we could quite easily open account
> creation back up with minimal risk and much lower moderator demand.

I think giving out delete permissions is a good first step, however if we are
going down this path of keep the wiki alive, I believe we have to look at
re-evaluating mediawiki.   Our current setup with puppet is not idea and I feel
mediawiki is maybe too much software for what we are doing.

I'd love to use something more easier to manage (ideally not php based).

> -- 
> Jeremy Stanley
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Sean Dague]

On 05/11/2016 01:51 PM, Jeremy Stanley wrote:
> On 2016-05-11 10:04:26 -0400 (-0400), Sean Dague wrote:
> [...]
>> Before deciding that it's unsurmountable, maybe giving delete
>> permissions to a larger set of contributors might be a good idea.
> [...]
> 
> I have no objection to granting delete (on non-locked articles) to
> all users immediately if someone works out the necessary
> configuration change to put that into effect. I expect it was
> restricted by default to encourage people to instead annotate
> articles as deprecated or use the "move" feature to redirect them to
> more relevant ones. That said, I think we're at the point where we
> should start considering such important content as candidates to
> move elsewhere outside the wiki (especially any currently remaining
> locked articles).
> 
>> I do realize running a public wiki is a PITA, especially at the
>> target level of openstack.org.
> [...]
> 
> The thing which would most significantly reduce its attractiveness
> to spammers would be to stop having major search engines index the
> content on it. Somewhere they can publish content and have it
> immediately show up in search engine results is really _all_ they
> care about. Maybe a compromise is to say that the wiki is an okay
> place to publish things you don't need people to find through
> external search engines? Then we could quite easily open account
> creation back up with minimal risk and much lower moderator demand.

Well, part of the reason for the wiki over etherpads is that it is
findable in google. This has been especially important when the search
engine in mediawiki stops updating itself (which has happened often
enough that it's a non theoretical issue).

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Jeremy Stanley]

On 2016-05-11 10:04:26 -0400 (-0400), Sean Dague wrote:
[...]
> Before deciding that it's unsurmountable, maybe giving delete
> permissions to a larger set of contributors might be a good idea.
[...]

I have no objection to granting delete (on non-locked articles) to
all users immediately if someone works out the necessary
configuration change to put that into effect. I expect it was
restricted by default to encourage people to instead annotate
articles as deprecated or use the "move" feature to redirect them to
more relevant ones. That said, I think we're at the point where we
should start considering such important content as candidates to
move elsewhere outside the wiki (especially any currently remaining
locked articles).

> I do realize running a public wiki is a PITA, especially at the
> target level of openstack.org.
[...]

The thing which would most significantly reduce its attractiveness
to spammers would be to stop having major search engines index the
content on it. Somewhere they can publish content and have it
immediately show up in search engine results is really _all_ they
care about. Maybe a compromise is to say that the wiki is an okay
place to publish things you don't need people to find through
external search engines? Then we could quite easily open account
creation back up with minimal risk and much lower moderator demand.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Matt Kassawara]

>From the perspective of contributing documentation and providing support
(mostly in #openstack) to a variety of consumers, the wiki tends to provide
yet another location for varying levels of content without a specific
audience and questionable relevance due to lack of maintenance. I find a
surprisingly large number of people referencing old content (OpenStack
sites and external sites such as personal blogs) because they don't
understand our release names or cycle length and the content doesn't always
make it clear. For documentation on OpenStack sites in particular, Google
doesn't help by ranking old content fairly high. I suspect that confusion
around preferred location of content and chronic frustration around
contributing to the central documentation (let's fix it! [1]) caused
sporadic growth of content on the wiki. Replacing the wiki with a
combination of more formal documentation and blog posts makes sense
providing the blog posts contain obvious publication dates (or relevant
release cycle) and, if necessary, some sort of deprecation notice to guide
consumers toward newer, more relevant content. Also, if content in a blog
post becomes more formal documentation, reference it.

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-May/094390.html

On Wed, May 11, 2016 at 8:44 AM, Thierry Carrez 
wrote:

> Thierry Carrez wrote:
>
>> [...]
>> I'll soon start a thread on that. Since that goes a lot beyond the dev
>> community, I'll post it to the openstack general list and post a pointer
>> to it here.
>>
>
> See
> http://lists.openstack.org/pipermail/openstack/2016-May/016154.html
>
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Thierry Carrez]

Thierry Carrez wrote:

[...]
I'll soon start a thread on that. Since that goes a lot beyond the dev
community, I'll post it to the openstack general list and post a pointer
to it here.


See
http://lists.openstack.org/pipermail/openstack/2016-May/016154.html

--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Sean Dague]

On 05/11/2016 05:53 AM, Thierry Carrez wrote:
> Tom Fifield wrote:
>> On 11/05/16 09:04, Dan Smith wrote:
 Here it is :)

 https://wiki.openstack.org/wiki/Special:AncientPages
>>>
>>> Great, I see at least one I can nuke on the first page.
>>>
>>> Note that I don't seem to have delete powers on the wiki. That's surely
>>> a first step in letting people maintain the relevance of things on the
>>> wiki.
>>
>> Looks like that was just fixed ... :)
> 
> Yes, and if people were as committed to cleaning up/maintaining old
> content as they are in creating new content, we'd certainly have a
> different discussion here.

Regular users don't have delete on the wiki (I know I don't). The only
way to actually delete things is to ask someone in infra. The last time
I asked about this was about 3 years ago and the policy was "don't
delete". I'm sure I'm not the only one that internalized that behavior.

Before deciding that it's unsurmountable, maybe giving delete
permissions to a larger set of contributors might be a good idea.

> To clarify, we do not plan to "just delete the wiki", we just continue
> to evolve our usage of it. We already moved most reference content out
> of it, and we'll continue to do so (since that is better served by a
> peer-reviewed website or proper documentation). The next step is to
> identify all the remaining use cases for the wiki -- all the people that
> use the wiki as a convenient/lightweight way to publish information.
> 
> Some of those use cases will be better served by other tools (think:
> TC/PTL election information should really live on the governance.o.o
> website), but there will always be a reminder of use cases for which a
> wiki (or some other comparably-lightweight publication platform) will be
> the best tool. The goal is to make sure we take into account all the use
> cases, as we investigate what tools could be used in the future.
> 
> I'll soon start a thread on that. Since that goes a lot beyond the dev
> community, I'll post it to the openstack general list and post a pointer
> to it here.
> 
> Cheers,

Ok, this is a different tone than seemed to come out of the first response.

That being said, the wiki is effectively crippled at this point with no
new accounts allowed. And with 40% of contributors every cycle being new
to OpenStack, the haves and the have nots for wiki access are going to
become a friction point before too long.

The wiki is a good domain where you can trust (but revert) quite easily,
so you can let anyone run and update a topic, and know that if you need
to revert is pretty simple 3 clicks and done. It is an on ramp where new
people in our community gain trust because we gave them tons of leeway,
knowing that we can revert if needed.

Etherpad gives lots of freedom, but reverting to a canonical form isn't
simple. Plus, no rich markup, which is often needed to explain ideas.

Git gives all the revert and markup power in the world, but includes
another review cycle. Someone other than the author has to push that
content in. For extremely formal documents, that's fine. But for a lot
of our popup workgroups, sprints, it's got too much friction to be
productive.

The absence of a functional wiki (or some other equivalent system where
permission to do almost anything is cheap, and reverts are easy) within
the project is mostly going to be people using 3rd party wikis, or
google docs, or other content systems outside the backup space of the
project. And, once people start actively scattering into those systems
and finding their groove, they are going to be quite slow to come back
into infra hosted systems for that content. The content will be sticky
where it is.

I do realize running a public wiki is a PITA, especially at the target
level of openstack.org. I also realize this is one of those spaces where
there are far more people that want to use a wiki than run one, so there
are no easy answers with new volunteers here.

As a community I think we need something in the space which is:

* new contributors can directly modify without having to ask permission
* supports rich markup (including images)
* is easy to revert to previous save point if we find something has gone
wrong

A wiki definitely hits these points. Other tech might as well. But a
wiki is also a known construct from open communities. So as solution
finding goes forward, please keep such things in mind.

-Sean

-- 
Sean Dague
http://dague.net



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Anita Kuno]

On 05/11/2016 05:07 AM, Daniel P. Berrange wrote:
> On Tue, May 10, 2016 at 12:59:41PM -0400, Anita Kuno wrote:
>> On 05/10/2016 12:48 PM, Dan Smith wrote:
> Hmm... that's unfortunate, as we were trying to get some of our less
> ephemeral items out of random etherpads and into the wiki (which has the
> value of being google indexed).
>>>
>>> Yeah, I'm kinda surprised anyone would consider a wiki-less world. I'm
>>> definitely bummed at the thought of losing it.
>>>
 The Google indexing is also what makes the wiki so painful... After 6
 years most of the content there is inaccurate or outdated. It's a
 massive effort to clean it up without breaking the Google juice, and
 nobody has the universal knowledge to determine if pages are still
 accurate or not. We are bitten every day by newcomers finding wrong
 information on the wiki and acting using it. It's getting worse every
 day we keep on using it.
>>>
>>> Sure, I think we all feel the pain of the stale information on the wiki.
>>> What if we were to do what we do for bug or review purges and make a
>>> list of pages, in reverse order of how recently they've been updated?
>>> Then we can have a few sprints to tag obviously outdated things to
>>> purge, and perhaps some things that just need some freshening.
>>>
>>> There are a lot of nova-related things on the wiki that are the
>>> prehistory equivalent of specs, most of which are very misleading to
>>> people about the current state of things. I would think we could purge a
>>> ton of stuff like that pretty quickly. I'll volunteer to review such a
>>> list from the nova perspective.
>>>
 * Deprecate the current wiki and start over with another wiki (with
 stronger ACL support ?)
>>>
>>> I'm somewhat surprised that this is an issue, because I thought that the
>>> wiki requires an ubuntu login. Are spammers really getting ubuntu logins
>>> so they can come over and deface our wiki?
>>
>> Yes.
> 
> Rather than blocking all new accounts, can we simply restrict new wiki 
> accounts
> to people who've signed the CLA ? That would at least allow all people who
> have taken the decision to become project contributors to continue to get
> access to the wiki. We surely won't have large numbers of spammers signing
> the CLA ??

Well it certainly would limit new wiki accounts, that is true.
Implementing the check would require the SSO bit to talk to the
foundation database bit. Having gerrit talking to the foundation
database bit is fraught with difficulty as it is, we have folks popping
into the infra channel everyday unable to submit changes to gerrit due
to not having the correct foundation membership or not having their
emails match on both systems. This connection is best described as
brittle. Adding in more dependence on it would simply put more burden on
infra to support folks wanting to use it (that is if is even possible to
create the check).

In addition, doing so sends entirely the wrong message. A separate
effort has been for some time to move us to an openid implementation
that takes us away from using UbuntuOne for many reasons, not the least
of which is the ability to drop the CLA requirement. The CLA requirement
has agreed to be dropped by both the TC and the Board, now we are
working hard to get the technology in place to make this a reality,
checking wiki account creation to CLA existance takes us in the wrong
direction.

Thanks Dan,
Anita.

> 
> Regards,
> Daniel
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Thierry Carrez]

Tom Fifield wrote:

On 11/05/16 09:04, Dan Smith wrote:

Here it is :)

https://wiki.openstack.org/wiki/Special:AncientPages


Great, I see at least one I can nuke on the first page.

Note that I don't seem to have delete powers on the wiki. That's surely
a first step in letting people maintain the relevance of things on the
wiki.


Looks like that was just fixed ... :)


Yes, and if people were as committed to cleaning up/maintaining old 
content as they are in creating new content, we'd certainly have a 
different discussion here.


To clarify, we do not plan to "just delete the wiki", we just continue 
to evolve our usage of it. We already moved most reference content out 
of it, and we'll continue to do so (since that is better served by a 
peer-reviewed website or proper documentation). The next step is to 
identify all the remaining use cases for the wiki -- all the people that 
use the wiki as a convenient/lightweight way to publish information.


Some of those use cases will be better served by other tools (think: 
TC/PTL election information should really live on the governance.o.o 
website), but there will always be a reminder of use cases for which a 
wiki (or some other comparably-lightweight publication platform) will be 
the best tool. The goal is to make sure we take into account all the use 
cases, as we investigate what tools could be used in the future.


I'll soon start a thread on that. Since that goes a lot beyond the dev 
community, I'll post it to the openstack general list and post a pointer 
to it here.


Cheers,

--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Daniel P. Berrange]

On Tue, May 10, 2016 at 12:59:41PM -0400, Anita Kuno wrote:
> On 05/10/2016 12:48 PM, Dan Smith wrote:
> >>> Hmm... that's unfortunate, as we were trying to get some of our less
> >>> ephemeral items out of random etherpads and into the wiki (which has the
> >>> value of being google indexed).
> > 
> > Yeah, I'm kinda surprised anyone would consider a wiki-less world. I'm
> > definitely bummed at the thought of losing it.
> > 
> >> The Google indexing is also what makes the wiki so painful... After 6
> >> years most of the content there is inaccurate or outdated. It's a
> >> massive effort to clean it up without breaking the Google juice, and
> >> nobody has the universal knowledge to determine if pages are still
> >> accurate or not. We are bitten every day by newcomers finding wrong
> >> information on the wiki and acting using it. It's getting worse every
> >> day we keep on using it.
> > 
> > Sure, I think we all feel the pain of the stale information on the wiki.
> > What if we were to do what we do for bug or review purges and make a
> > list of pages, in reverse order of how recently they've been updated?
> > Then we can have a few sprints to tag obviously outdated things to
> > purge, and perhaps some things that just need some freshening.
> > 
> > There are a lot of nova-related things on the wiki that are the
> > prehistory equivalent of specs, most of which are very misleading to
> > people about the current state of things. I would think we could purge a
> > ton of stuff like that pretty quickly. I'll volunteer to review such a
> > list from the nova perspective.
> > 
> >> * Deprecate the current wiki and start over with another wiki (with
> >> stronger ACL support ?)
> > 
> > I'm somewhat surprised that this is an issue, because I thought that the
> > wiki requires an ubuntu login. Are spammers really getting ubuntu logins
> > so they can come over and deface our wiki?
> 
> Yes.

Rather than blocking all new accounts, can we simply restrict new wiki accounts
to people who've signed the CLA ? That would at least allow all people who
have taken the decision to become project contributors to continue to get
access to the wiki. We surely won't have large numbers of spammers signing
the CLA ??

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Tom Fifield]

On 11/05/16 09:04, Dan Smith wrote:

Here it is :)

https://wiki.openstack.org/wiki/Special:AncientPages


Great, I see at least one I can nuke on the first page.

Note that I don't seem to have delete powers on the wiki. That's surely
a first step in letting people maintain the relevance of things on the wiki.


Looks like that was just fixed ... :)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Dan Smith]

> Here it is :)
> 
> https://wiki.openstack.org/wiki/Special:AncientPages

Great, I see at least one I can nuke on the first page.

Note that I don't seem to have delete powers on the wiki. That's surely
a first step in letting people maintain the relevance of things on the wiki.

--Dan

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Tom Fifield]

On 11/05/16 02:48, Dan Smith wrote:

Hmm... that's unfortunate, as we were trying to get some of our less
ephemeral items out of random etherpads and into the wiki (which has the
value of being google indexed).


Yeah, I'm kinda surprised anyone would consider a wiki-less world. I'm
definitely bummed at the thought of losing it.


The Google indexing is also what makes the wiki so painful... After 6
years most of the content there is inaccurate or outdated. It's a
massive effort to clean it up without breaking the Google juice, and
nobody has the universal knowledge to determine if pages are still
accurate or not. We are bitten every day by newcomers finding wrong
information on the wiki and acting using it. It's getting worse every
day we keep on using it.


Sure, I think we all feel the pain of the stale information on the wiki.
What if we were to do what we do for bug or review purges and make a
list of pages, in reverse order of how recently they've been updated?
Then we can have a few sprints to tag obviously outdated things to
purge, and perhaps some things that just need some freshening.


Here it is :)

https://wiki.openstack.org/wiki/Special:AncientPages

MediaWiki also has some other useful tools installed by default:

https://wiki.openstack.org/wiki/Special:SpecialPages

There are also a series of plugins, such as the ones for "patrolling" 
edits, and bots for mass updates and triggers that would potentially be 
helpful.



There are a lot of nova-related things on the wiki that are the
prehistory equivalent of specs, most of which are very misleading to
people about the current state of things. I would think we could purge a
ton of stuff like that pretty quickly. I'll volunteer to review such a
list from the nova perspective.


* Deprecate the current wiki and start over with another wiki (with
stronger ACL support ?)


I'm somewhat surprised that this is an issue, because I thought that the
wiki requires an ubuntu login. Are spammers really getting ubuntu logins
so they can come over and deface our wiki?

--Dan

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Jeremy Stanley]

On 2016-05-11 08:49:14 +1200 (+1200), Robert Collins wrote:
[...]
> Ubuntu SSO is **not** Launchpad. Launchpad is just another consumer of
> Ubuntu SSO, and it has the 'feature' of forwarding through to Ubuntu
> SSO - so we're actually seeing Ubuntu SSO spam accounts :(.
[...]

Thanks for the correction, you're right that's actually what I
meant (I should be more careful not to accidentally conflate the two
with vague terminology).

In fact I went so far as trying to track them back to Launchpad
profiles via the LP API's OpenID reverse lookup method and confirmed
they don't have any, so they're using login.launchpad.net to create
accounts to spam various places (our wiki, the Ubuntu wiki,
and presumably lots of others too). I think that means, at least in
most cases, they're probably not actually preexisting compromised
accounts and just new accounts created solely for the purpose of
spamming places relying on the Ubuntu SSO for authentication.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Robert Collins]

On 11 May 2016 at 08:27, Jeremy Stanley  wrote:

>
> Anyway, to the original point, yes Launchpad is full of compromised
> or perhaps freshly created accounts under the control of spammers.

Ubuntu SSO is **not** Launchpad. Launchpad is just another consumer of
Ubuntu SSO, and it has the 'feature' of forwarding through to Ubuntu
SSO - so we're actually seeing Ubuntu SSO spam accounts :(.

Why does this matter? If folk want to solve this at source - make
making new accounts harder - you need to look at the correct code
base, which is https://launchpad.net/canonical-identity-provider

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Jeremy Stanley]

On 2016-05-10 20:17:43 + (+), Jeremy Stanley wrote:
[...]
> Last I heard, wiki.ubuntu.com has been made read-only for general
> users because they're having too hard a time keeping spam under
> control (they obviously also use
> login.launchpad.net/login.ubuntu.com). I'm trying to create an
> account there right now to confirm whether this is still the case,
> and the post-OpenID page which should in theory be creating my
> account is timing out in my browser with a 500 ISR after several
> minutes).

Just to follow up, after a few tries I finally got one to go
through. It looks like editing existing pages may still work (I
haven't tried to save an edit) though creating new pages seems to be
a forbidden action at the moment.

Anyway, to the original point, yes Launchpad is full of compromised
or perhaps freshly created accounts under the control of spammers.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Jeremy Stanley]

On 2016-05-10 12:59:41 -0400 (-0400), Anita Kuno wrote:
> On 05/10/2016 12:48 PM, Dan Smith wrote:
[...]
> > I'm somewhat surprised that this is an issue, because I thought
> > that the wiki requires an ubuntu login. Are spammers really
> > getting ubuntu logins so they can come over and deface our wiki?
> 
> Yes.

We've temporarily (for a couple months now) halted new account
creation on wiki.openstack.org while we work through better spam
mitigation. Last I heard, wiki.ubuntu.com has been made read-only
for general users because they're having too hard a time keeping
spam under control (they obviously also use
login.launchpad.net/login.ubuntu.com). I'm trying to create an
account there right now to confirm whether this is still the case,
and the post-OpenID page which should in theory be creating my
account is timing out in my browser with a 500 ISR after several
minutes).
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Anita Kuno]

On 05/10/2016 12:48 PM, Dan Smith wrote:
>>> Hmm... that's unfortunate, as we were trying to get some of our less
>>> ephemeral items out of random etherpads and into the wiki (which has the
>>> value of being google indexed).
> 
> Yeah, I'm kinda surprised anyone would consider a wiki-less world. I'm
> definitely bummed at the thought of losing it.
> 
>> The Google indexing is also what makes the wiki so painful... After 6
>> years most of the content there is inaccurate or outdated. It's a
>> massive effort to clean it up without breaking the Google juice, and
>> nobody has the universal knowledge to determine if pages are still
>> accurate or not. We are bitten every day by newcomers finding wrong
>> information on the wiki and acting using it. It's getting worse every
>> day we keep on using it.
> 
> Sure, I think we all feel the pain of the stale information on the wiki.
> What if we were to do what we do for bug or review purges and make a
> list of pages, in reverse order of how recently they've been updated?
> Then we can have a few sprints to tag obviously outdated things to
> purge, and perhaps some things that just need some freshening.
> 
> There are a lot of nova-related things on the wiki that are the
> prehistory equivalent of specs, most of which are very misleading to
> people about the current state of things. I would think we could purge a
> ton of stuff like that pretty quickly. I'll volunteer to review such a
> list from the nova perspective.
> 
>> * Deprecate the current wiki and start over with another wiki (with
>> stronger ACL support ?)
> 
> I'm somewhat surprised that this is an issue, because I thought that the
> wiki requires an ubuntu login. Are spammers really getting ubuntu logins
> so they can come over and deface our wiki?

Yes.

> 
> --Dan
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Dan Smith]

>> Hmm... that's unfortunate, as we were trying to get some of our less
>> ephemeral items out of random etherpads and into the wiki (which has the
>> value of being google indexed).

Yeah, I'm kinda surprised anyone would consider a wiki-less world. I'm
definitely bummed at the thought of losing it.

> The Google indexing is also what makes the wiki so painful... After 6
> years most of the content there is inaccurate or outdated. It's a
> massive effort to clean it up without breaking the Google juice, and
> nobody has the universal knowledge to determine if pages are still
> accurate or not. We are bitten every day by newcomers finding wrong
> information on the wiki and acting using it. It's getting worse every
> day we keep on using it.

Sure, I think we all feel the pain of the stale information on the wiki.
What if we were to do what we do for bug or review purges and make a
list of pages, in reverse order of how recently they've been updated?
Then we can have a few sprints to tag obviously outdated things to
purge, and perhaps some things that just need some freshening.

There are a lot of nova-related things on the wiki that are the
prehistory equivalent of specs, most of which are very misleading to
people about the current state of things. I would think we could purge a
ton of stuff like that pretty quickly. I'll volunteer to review such a
list from the nova perspective.

> * Deprecate the current wiki and start over with another wiki (with
> stronger ACL support ?)

I'm somewhat surprised that this is an issue, because I thought that the
wiki requires an ubuntu login. Are spammers really getting ubuntu logins
so they can come over and deface our wiki?

--Dan

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki

[Joshua Harlow]

Thierry Carrez wrote:

Sean Dague wrote:

On 05/09/2016 06:53 PM, Monty Taylor wrote:

On 05/09/2016 05:45 PM, Robert Collins wrote:

IIRC mediawiki provides RSS of changes... maybe just using the wiki
more would be a good start, and have zero infra costs?


We'd actually like to start using the wiki less, per the most recent
summit. Also, the wiki currently has new accounts turned off (thanks
spammers) so if you don't have a wiki account now, you're not getting
one soon.


Hmm... that's unfortunate, as we were trying to get some of our less
ephemeral items out of random etherpads and into the wiki (which has the
value of being google indexed).


The Google indexing is also what makes the wiki so painful... After 6
years most of the content there is inaccurate or outdated. It's a
massive effort to clean it up without breaking the Google juice, and
nobody has the universal knowledge to determine if pages are still
accurate or not. We are bitten every day by newcomers finding wrong
information on the wiki and acting using it. It's getting worse every
day we keep on using it.

Also the Google juice is what made our wiki a target for spammers /
defacers. We don't have an army of maintainers like wikipedia ready to
jump at any defacement, so the fully open nature of the wiki which makes
it so convenient (anyone can create or modify a page), is also it's
major flaw (anyone can create or modify a page).

We moved most of the reference information out of the wiki to proper
documentation and peer-reviewed websites (security.o.o, governance.o.o,
releases.o.o...) but we still need somewhere to easily publish random
pages -- something between etherpad (too transient) and proper
documentation (too formal). Ideally the new tool would make it clear
that the page is not canonical information, so that we avoid the wiki
effect. Three options:

* Keep the current wiki to achieve that (valid option if we have a whole
team of wiki gardeners to weed out outdated pages and watch for
spam/defacement -- and history proved that we don't)

* Drop the current wiki and replace it by another lightweight
publication solution (if there is anything convenient)

* Deprecate the current wiki and start over with another wiki (with
stronger ACL support ?)



Would the previous topic (team blogs) that this was be a good 
replacement, if information on the wiki is project specific then why not 
just allow each project to have a blog and/or wiki-blog combination and 
then the project that owns the blog/wiki-blog would be responsible for 
maintaining it...


I don't know if any software solution exists for this, but I guess we 
are all brainstorming anyway :)


-Josh

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Wiki (was: Team blogs)

[Thierry Carrez]

Sean Dague wrote:

On 05/09/2016 06:53 PM, Monty Taylor wrote:

On 05/09/2016 05:45 PM, Robert Collins wrote:

IIRC mediawiki provides RSS of changes... maybe just using the wiki
more would be a good start, and have zero infra costs?


We'd actually like to start using the wiki less, per the most recent
summit. Also, the wiki currently has new accounts turned off (thanks
spammers) so if you don't have a wiki account now, you're not getting
one soon.


Hmm... that's unfortunate, as we were trying to get some of our less
ephemeral items out of random etherpads and into the wiki (which has the
value of being google indexed).


The Google indexing is also what makes the wiki so painful... After 6 
years most of the content there is inaccurate or outdated. It's a 
massive effort to clean it up without breaking the Google juice, and 
nobody has the universal knowledge to determine if pages are still 
accurate or not. We are bitten every day by newcomers finding wrong 
information on the wiki and acting using it. It's getting worse every 
day we keep on using it.


Also the Google juice is what made our wiki a target for spammers / 
defacers. We don't have an army of maintainers like wikipedia ready to 
jump at any defacement, so the fully open nature of the wiki which makes 
it so convenient (anyone can create or modify a page), is also it's 
major flaw (anyone can create or modify a page).


We moved most of the reference information out of the wiki to proper 
documentation and peer-reviewed websites (security.o.o, governance.o.o, 
releases.o.o...) but we still need somewhere to easily publish random 
pages -- something between etherpad (too transient) and proper 
documentation (too formal). Ideally the new tool would make it clear 
that the page is not canonical information, so that we avoid the wiki 
effect. Three options:


* Keep the current wiki to achieve that (valid option if we have a whole 
team of wiki gardeners to weed out outdated pages and watch for 
spam/defacement -- and history proved that we don't)


* Drop the current wiki and replace it by another lightweight 
publication solution (if there is anything convenient)


* Deprecate the current wiki and start over with another wiki (with 
stronger ACL support ?)


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev