Re: Strategic Planning: Website

[Andrea Pescetti]

On 07/03/2013 janI wrote:

On 7 March 2013 09:53, Andrea Pescetti wrote:

MWiki ... has been updated with a huge
effort lead by Jan, and it is now stable and reliable.

I totally agree with this point of view, but when a PMC raises doubt about
using Mwiki, it is something we all have to listen carefully to, afterall
one of the points in being PMC is to secure the long term stability of the
community and product.


I've already written this, but there is nothing really special about PMC 
members: when people express opinions here, they are just people 
expressing an opinion, and the content, not the author, makes the 
difference.



At the moment we have no-one with "just" shell access, all 3 have (or can
have) root access. Furthermore rjung (infra) pratically maintains httpd,
gmcdonald (infra-root) helps with more or less everything and Clayton helps
with mwiki setup (without access).


And this is very nice to know. So basically we are not depending on one 
person only for everything related to MWiki. There is already a team of 
active people who (with different responsibilities) help in keeping 
MWiki efficient.


The advice I got from Infra is:

1) Project-specific tools should be maintained by the project; but this 
doesn't mean that Infra is going to ignore issues; Infra will work with 
the project to fix urgent issues and will possibly help, but not with 
the priority it gives to supported applications; shutting down an 
insecure application is not impossible, but it is still very rare.


2) Keep software up-to-date, and here, aside from the discussion about 
separating security-related discussions and volunteers for testing 
updates, I believe everything is clear.


3) Keep the upgrade process documented. You mentioned it is in SVN. 
Where exactly? This is probably more important than directly instructing 
more volunteers, since clear instructions are everything Infra (or 
whoever has a working knowledge of LAMP setup, including me for that 
matter) needs in case there is an urgent issue.


So I don't feel too worried about MWiki and Forum knowing that Infra has 
root access to the machines, that we have clear maintenance (and 
especially upgrade) instructions somewhere and that we have volunteers 
who are able to use those instructions (even though I'd like to see 
imacat or rbircher or someone clearly stating that they are prepared to 
take over if you are unreachable). The past history of MWiki does not 
look so good, but we had many different priorities at the time. The 
countermeasures above will significantly mitigate the risk that we feel 
that our tools are unmaintained.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Strategic Planning: Website

[Jürgen Schmidt]

On 3/7/13 2:56 PM, janI wrote:
> On 7 March 2013 09:53, Andrea Pescetti  wrote:
> 
>> Rob Weir wrote:
>>
>>> On Wed, Mar 6, 2013 at 5:46 PM, Kay Schenk wrote:
>>>
 "Sustainability concerns due to our use of unsupported applications (from
 Apache Infra perspective), including phpBB and MWiki and reliance on a
 very
 small number of system admins." ...
 https://cwiki.apache.org/**confluence/display/OOOUSERS/**
 Website+Strategic+Plan

>>> And let's not forget alternative ways of addressing this concern:
>>> 1) Work with Infra to make MWiki be officially supported.
>>> or
>>> 2) Form our own admin group
>>>
>>
>> Indeed, I see no reasons to revisit, especially at the current stage, the
>> MWiki vs [any other wiki] issue.
>>
>> MWiki is the biggest source of information about the project; while its
>> content is often outdated, it's still very useful. Existing links to the
>> MWiki pages are in the thousands (or more). It has been updated with a huge
>> effort lead by Jan, and it is now stable and reliable.
>>
> 
> I totally agree with this point of view, but when a PMC raises doubt about
> using Mwiki, it is something we all have to listen carefully to, afterall
> one of the points in being PMC is to secure the long term stability of the
> community and product.
> 
> This is also the reason I researched cwiki and moin...not that I personally
> would like to change, but because I read the mail from one PMC and the
> reactions from others.
> 
> 
>>
>> If our problem is to enlarge the administrators group for MWiki or to get
>> it officially supported, I prefer to explore these options first. We
>> already have three committers who can administer MWiki on the system
>> administration (shell access) side, right? (jani, imacat, rbircher). How
>> many more do we need? I've also just asked Infra for clarifications about
>> the "supported applications" issue.
>>
> 
> At the moment we have no-one with "just" shell access, all 3 have (or can
> have) root access. Furthermore rjung (infra) pratically maintains httpd,
> gmcdonald (infra-root) helps with more or less everything and Clayton helps
> with mwiki setup (without access). BIG Thanks to all three for their great
> help !
> 
> After the upgrade we have had one incident (which rjung handled), one
> upgrade proposition (which I handled wrong) and 2 request for change (one
> pending and one I have handled). At the same time, nothing have been done
> "inside" mwiki regarding old pages, strange categories, spammed paged,
> misleading information.
> 
> At the moment 2/3 of the time I use on mwiki goes to logistic and
> coordinating people, if the group is expanded my experience is that the
> overhead grows exponentially. I respect the wish of the community and when
> the group is expanded, I will withdraw (after a handover), I am here to get
> things done and not to coordinate people.
> 
> I fully understand we need many sysop, and the idea of having a mail list
> (or just a wiki-page, with sysop access level) is a good idea. Our biggest
> job at the moment is not sys-admin but normal sysop work.

I think we mainly need admins with the skills to do the maintenance
work. Jan have shown his expertise and drove things forward and helped
with critical issues like the spam attack. If somebody volunteer to help
out here it is important to be committed to do the job in some way. It
doesn't help us to have a list of admins where only one is active. It's
no problem if priorities are changing over time but it have to be
communicated. And if the skills are not present I would expect that the
volunteer is willing to learn from the other sysops over time to build
the necessary skills.

We should also think about some kind of knowledge base where we document
related things that are specific to our installation etc.

> 
> I honestly think we should consider more how to stabilize the "inside" of
> mwiki instead of focussing on the sysadmin part, but that is just my
> opinion.

I think it's probably a combination of both. The group of admins can
leverage each other to build the knowledge and work together on a stable
and secure setup.

Juergen


> 
> rgds
> Jan I.
> 
> 
> 
> 
> 
>>
>> Regards,
>>   Andrea.
>>
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> dev-unsubscribe@openoffice.**apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Strategic Planning: Website

[Rob Weir]

On Thu, Mar 7, 2013 at 10:33 AM, janI  wrote:
> On 7 March 2013 15:55, Rob Weir  wrote:
>
>> On Thu, Mar 7, 2013 at 8:56 AM, janI  wrote:
>> > On 7 March 2013 09:53, Andrea Pescetti  wrote:
>> >
>> >> Rob Weir wrote:
>> >>
>> >>> On Wed, Mar 6, 2013 at 5:46 PM, Kay Schenk wrote:
>> >>>
>>  "Sustainability concerns due to our use of unsupported applications
>> (from
>>  Apache Infra perspective), including phpBB and MWiki and reliance on a
>>  very
>>  small number of system admins." ...
>>  https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>>  Website+Strategic+Plan<
>> https://cwiki.apache.org/confluence/display/OOOUSERS/Website+Strategic+Plan
>> >
>> 
>> >>> And let's not forget alternative ways of addressing this concern:
>> >>> 1) Work with Infra to make MWiki be officially supported.
>> >>> or
>> >>> 2) Form our own admin group
>> >>>
>> >>
>> >> Indeed, I see no reasons to revisit, especially at the current stage,
>> the
>> >> MWiki vs [any other wiki] issue.
>> >>
>> >> MWiki is the biggest source of information about the project; while its
>> >> content is often outdated, it's still very useful. Existing links to the
>> >> MWiki pages are in the thousands (or more). It has been updated with a
>> huge
>> >> effort lead by Jan, and it is now stable and reliable.
>> >>
>> >
>> > I totally agree with this point of view, but when a PMC raises doubt
>> about
>> > using Mwiki, it is something we all have to listen carefully to, afterall
>> > one of the points in being PMC is to secure the long term stability of
>> the
>> > community and product.
>> >
>> > This is also the reason I researched cwiki and moin...not that I
>> personally
>> > would like to change, but because I read the mail from one PMC and the
>> > reactions from others.
>> >
>>
>> But please note that I never suggested moving off of MWiki.
>>
>> >
>> >>
>> >> If our problem is to enlarge the administrators group for MWiki or to
>> get
>> >> it officially supported, I prefer to explore these options first. We
>> >> already have three committers who can administer MWiki on the system
>> >> administration (shell access) side, right? (jani, imacat, rbircher). How
>> >> many more do we need? I've also just asked Infra for clarifications
>> about
>> >> the "supported applications" issue.
>> >>
>> >
>> > At the moment we have no-one with "just" shell access, all 3 have (or can
>> > have) root access. Furthermore rjung (infra) pratically maintains httpd,
>> > gmcdonald (infra-root) helps with more or less everything and Clayton
>> helps
>> > with mwiki setup (without access). BIG Thanks to all three for their
>> great
>> > help !
>> >
>> > After the upgrade we have had one incident (which rjung handled), one
>> > upgrade proposition (which I handled wrong) and 2 request for change (one
>> > pending and one I have handled). At the same time, nothing have been done
>> > "inside" mwiki regarding old pages, strange categories, spammed paged,
>> > misleading information.
>> >
>> > At the moment 2/3 of the time I use on mwiki goes to logistic and
>> > coordinating people, if the group is expanded my experience is that the
>> > overhead grows exponentially. I respect the wish of the community and
>> when
>> > the group is expanded, I will withdraw (after a handover), I am here to
>> get
>> > things done and not to coordinate people.
>> >
>> > I fully understand we need many sysop, and the idea of having a mail list
>> > (or just a wiki-page, with sysop access level) is a good idea. Our
>> biggest
>> > job at the moment is not sys-admin but normal sysop work.
>> >
>>
>> This is what I see:
>>
>> 1) We brought over MWiki and had a single person (Terry) who really
>> knew what was going on.  We may have had others who had permissions,
>> but they were not (IMHO) able to keep the wiki stable.
>>
>> 2) Terry left, and the wiki was not maintained as well.  Eventually it
>> fell due to massive spam.  No one of the existing admins stepped up to
>> fix the problem.  Whether this was from skill, permissions, time,
>> inclination, I don't know and I don't judge.  But the actions were to
>> disable new account creation and treat that as a new way of life.
>>
>> 3) You stepped up and took the lead on getting MWiki to be properly
>> maintained again.  If you had not done that I am pretty sure that we
>> would not have the ability for new years to create accounts today.  We
>> were already down on one knee when you offered to help.  I'm pretty
>> sure without your help things would continue to degrade.
>>
>> 4) So what would things look like without you?  Sure we have others
>> who have some permissions.  But is that enough?  (It wasn't enough
>> before).  What do we need to do so we are not dependent on a single
>> person?  Not just from a theoretical standpoint (X and Y have
>> permissions) but from a practical skill and knowledge level as well.
>>
>
> I think there are too much focus on the sysadmin part, which isnt really a
> prob

Re: Strategic Planning: Website

[janI]

On 7 March 2013 15:55, Rob Weir  wrote:

> On Thu, Mar 7, 2013 at 8:56 AM, janI  wrote:
> > On 7 March 2013 09:53, Andrea Pescetti  wrote:
> >
> >> Rob Weir wrote:
> >>
> >>> On Wed, Mar 6, 2013 at 5:46 PM, Kay Schenk wrote:
> >>>
>  "Sustainability concerns due to our use of unsupported applications
> (from
>  Apache Infra perspective), including phpBB and MWiki and reliance on a
>  very
>  small number of system admins." ...
>  https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>  Website+Strategic+Plan<
> https://cwiki.apache.org/confluence/display/OOOUSERS/Website+Strategic+Plan
> >
> 
> >>> And let's not forget alternative ways of addressing this concern:
> >>> 1) Work with Infra to make MWiki be officially supported.
> >>> or
> >>> 2) Form our own admin group
> >>>
> >>
> >> Indeed, I see no reasons to revisit, especially at the current stage,
> the
> >> MWiki vs [any other wiki] issue.
> >>
> >> MWiki is the biggest source of information about the project; while its
> >> content is often outdated, it's still very useful. Existing links to the
> >> MWiki pages are in the thousands (or more). It has been updated with a
> huge
> >> effort lead by Jan, and it is now stable and reliable.
> >>
> >
> > I totally agree with this point of view, but when a PMC raises doubt
> about
> > using Mwiki, it is something we all have to listen carefully to, afterall
> > one of the points in being PMC is to secure the long term stability of
> the
> > community and product.
> >
> > This is also the reason I researched cwiki and moin...not that I
> personally
> > would like to change, but because I read the mail from one PMC and the
> > reactions from others.
> >
>
> But please note that I never suggested moving off of MWiki.
>
> >
> >>
> >> If our problem is to enlarge the administrators group for MWiki or to
> get
> >> it officially supported, I prefer to explore these options first. We
> >> already have three committers who can administer MWiki on the system
> >> administration (shell access) side, right? (jani, imacat, rbircher). How
> >> many more do we need? I've also just asked Infra for clarifications
> about
> >> the "supported applications" issue.
> >>
> >
> > At the moment we have no-one with "just" shell access, all 3 have (or can
> > have) root access. Furthermore rjung (infra) pratically maintains httpd,
> > gmcdonald (infra-root) helps with more or less everything and Clayton
> helps
> > with mwiki setup (without access). BIG Thanks to all three for their
> great
> > help !
> >
> > After the upgrade we have had one incident (which rjung handled), one
> > upgrade proposition (which I handled wrong) and 2 request for change (one
> > pending and one I have handled). At the same time, nothing have been done
> > "inside" mwiki regarding old pages, strange categories, spammed paged,
> > misleading information.
> >
> > At the moment 2/3 of the time I use on mwiki goes to logistic and
> > coordinating people, if the group is expanded my experience is that the
> > overhead grows exponentially. I respect the wish of the community and
> when
> > the group is expanded, I will withdraw (after a handover), I am here to
> get
> > things done and not to coordinate people.
> >
> > I fully understand we need many sysop, and the idea of having a mail list
> > (or just a wiki-page, with sysop access level) is a good idea. Our
> biggest
> > job at the moment is not sys-admin but normal sysop work.
> >
>
> This is what I see:
>
> 1) We brought over MWiki and had a single person (Terry) who really
> knew what was going on.  We may have had others who had permissions,
> but they were not (IMHO) able to keep the wiki stable.
>
> 2) Terry left, and the wiki was not maintained as well.  Eventually it
> fell due to massive spam.  No one of the existing admins stepped up to
> fix the problem.  Whether this was from skill, permissions, time,
> inclination, I don't know and I don't judge.  But the actions were to
> disable new account creation and treat that as a new way of life.
>
> 3) You stepped up and took the lead on getting MWiki to be properly
> maintained again.  If you had not done that I am pretty sure that we
> would not have the ability for new years to create accounts today.  We
> were already down on one knee when you offered to help.  I'm pretty
> sure without your help things would continue to degrade.
>
> 4) So what would things look like without you?  Sure we have others
> who have some permissions.  But is that enough?  (It wasn't enough
> before).  What do we need to do so we are not dependent on a single
> person?  Not just from a theoretical standpoint (X and Y have
> permissions) but from a practical skill and knowledge level as well.
>

I think there are too much focus on the sysadmin part, which isnt really a
problem..mwiki is very stable, it needs an upgrade now and then (2 times a
year in average). Our httpd, ats, firewall, ubuntu needs a lot more regular
maintenance, and tha

Re: Strategic Planning: Website

[Rob Weir]

On Thu, Mar 7, 2013 at 8:56 AM, janI  wrote:
> On 7 March 2013 09:53, Andrea Pescetti  wrote:
>
>> Rob Weir wrote:
>>
>>> On Wed, Mar 6, 2013 at 5:46 PM, Kay Schenk wrote:
>>>
 "Sustainability concerns due to our use of unsupported applications (from
 Apache Infra perspective), including phpBB and MWiki and reliance on a
 very
 small number of system admins." ...
 https://cwiki.apache.org/**confluence/display/OOOUSERS/**
 Website+Strategic+Plan

>>> And let's not forget alternative ways of addressing this concern:
>>> 1) Work with Infra to make MWiki be officially supported.
>>> or
>>> 2) Form our own admin group
>>>
>>
>> Indeed, I see no reasons to revisit, especially at the current stage, the
>> MWiki vs [any other wiki] issue.
>>
>> MWiki is the biggest source of information about the project; while its
>> content is often outdated, it's still very useful. Existing links to the
>> MWiki pages are in the thousands (or more). It has been updated with a huge
>> effort lead by Jan, and it is now stable and reliable.
>>
>
> I totally agree with this point of view, but when a PMC raises doubt about
> using Mwiki, it is something we all have to listen carefully to, afterall
> one of the points in being PMC is to secure the long term stability of the
> community and product.
>
> This is also the reason I researched cwiki and moin...not that I personally
> would like to change, but because I read the mail from one PMC and the
> reactions from others.
>

But please note that I never suggested moving off of MWiki.

>
>>
>> If our problem is to enlarge the administrators group for MWiki or to get
>> it officially supported, I prefer to explore these options first. We
>> already have three committers who can administer MWiki on the system
>> administration (shell access) side, right? (jani, imacat, rbircher). How
>> many more do we need? I've also just asked Infra for clarifications about
>> the "supported applications" issue.
>>
>
> At the moment we have no-one with "just" shell access, all 3 have (or can
> have) root access. Furthermore rjung (infra) pratically maintains httpd,
> gmcdonald (infra-root) helps with more or less everything and Clayton helps
> with mwiki setup (without access). BIG Thanks to all three for their great
> help !
>
> After the upgrade we have had one incident (which rjung handled), one
> upgrade proposition (which I handled wrong) and 2 request for change (one
> pending and one I have handled). At the same time, nothing have been done
> "inside" mwiki regarding old pages, strange categories, spammed paged,
> misleading information.
>
> At the moment 2/3 of the time I use on mwiki goes to logistic and
> coordinating people, if the group is expanded my experience is that the
> overhead grows exponentially. I respect the wish of the community and when
> the group is expanded, I will withdraw (after a handover), I am here to get
> things done and not to coordinate people.
>
> I fully understand we need many sysop, and the idea of having a mail list
> (or just a wiki-page, with sysop access level) is a good idea. Our biggest
> job at the moment is not sys-admin but normal sysop work.
>

This is what I see:

1) We brought over MWiki and had a single person (Terry) who really
knew what was going on.  We may have had others who had permissions,
but they were not (IMHO) able to keep the wiki stable.

2) Terry left, and the wiki was not maintained as well.  Eventually it
fell due to massive spam.  No one of the existing admins stepped up to
fix the problem.  Whether this was from skill, permissions, time,
inclination, I don't know and I don't judge.  But the actions were to
disable new account creation and treat that as a new way of life.

3) You stepped up and took the lead on getting MWiki to be properly
maintained again.  If you had not done that I am pretty sure that we
would not have the ability for new years to create accounts today.  We
were already down on one knee when you offered to help.  I'm pretty
sure without your help things would continue to degrade.

4) So what would things look like without you?  Sure we have others
who have some permissions.  But is that enough?  (It wasn't enough
before).  What do we need to do so we are not dependent on a single
person?  Not just from a theoretical standpoint (X and Y have
permissions) but from a practical skill and knowledge level as well.

5) Note the same applies to phpBB as well.

>From a high-level perspective, one way is to think of it like this:
As a large project with diverse technical infrastructure we make high
demands on Infra, hardware, bandwidth, sys admin time, etc.  Since we
have such a dependency on this technical infrastructure, more so than
other Apache projects which are less end-user facing, this starts us
off with greater risks.  Our use of non-standard services like MWiki
and phpBB increases the risk.  Fine. So how do 

Re: Strategic Planning: Website

[janI]

On 7 March 2013 09:53, Andrea Pescetti  wrote:

> Rob Weir wrote:
>
>> On Wed, Mar 6, 2013 at 5:46 PM, Kay Schenk wrote:
>>
>>> "Sustainability concerns due to our use of unsupported applications (from
>>> Apache Infra perspective), including phpBB and MWiki and reliance on a
>>> very
>>> small number of system admins." ...
>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
>>> Website+Strategic+Plan
>>>
>> And let's not forget alternative ways of addressing this concern:
>> 1) Work with Infra to make MWiki be officially supported.
>> or
>> 2) Form our own admin group
>>
>
> Indeed, I see no reasons to revisit, especially at the current stage, the
> MWiki vs [any other wiki] issue.
>
> MWiki is the biggest source of information about the project; while its
> content is often outdated, it's still very useful. Existing links to the
> MWiki pages are in the thousands (or more). It has been updated with a huge
> effort lead by Jan, and it is now stable and reliable.
>

I totally agree with this point of view, but when a PMC raises doubt about
using Mwiki, it is something we all have to listen carefully to, afterall
one of the points in being PMC is to secure the long term stability of the
community and product.

This is also the reason I researched cwiki and moin...not that I personally
would like to change, but because I read the mail from one PMC and the
reactions from others.


>
> If our problem is to enlarge the administrators group for MWiki or to get
> it officially supported, I prefer to explore these options first. We
> already have three committers who can administer MWiki on the system
> administration (shell access) side, right? (jani, imacat, rbircher). How
> many more do we need? I've also just asked Infra for clarifications about
> the "supported applications" issue.
>

At the moment we have no-one with "just" shell access, all 3 have (or can
have) root access. Furthermore rjung (infra) pratically maintains httpd,
gmcdonald (infra-root) helps with more or less everything and Clayton helps
with mwiki setup (without access). BIG Thanks to all three for their great
help !

After the upgrade we have had one incident (which rjung handled), one
upgrade proposition (which I handled wrong) and 2 request for change (one
pending and one I have handled). At the same time, nothing have been done
"inside" mwiki regarding old pages, strange categories, spammed paged,
misleading information.

At the moment 2/3 of the time I use on mwiki goes to logistic and
coordinating people, if the group is expanded my experience is that the
overhead grows exponentially. I respect the wish of the community and when
the group is expanded, I will withdraw (after a handover), I am here to get
things done and not to coordinate people.

I fully understand we need many sysop, and the idea of having a mail list
(or just a wiki-page, with sysop access level) is a good idea. Our biggest
job at the moment is not sys-admin but normal sysop work.

I honestly think we should consider more how to stabilize the "inside" of
mwiki instead of focussing on the sysadmin part, but that is just my
opinion.

rgds
Jan I.





>
> Regards,
>   Andrea.
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Strategic Planning: Website

[Andrea Pescetti]

Rob Weir wrote:

On Wed, Mar 6, 2013 at 5:46 PM, Kay Schenk wrote:

"Sustainability concerns due to our use of unsupported applications (from
Apache Infra perspective), including phpBB and MWiki and reliance on a very
small number of system admins." ...
https://cwiki.apache.org/confluence/display/OOOUSERS/Website+Strategic+Plan

And let's not forget alternative ways of addressing this concern:
1) Work with Infra to make MWiki be officially supported.
or
2) Form our own admin group


Indeed, I see no reasons to revisit, especially at the current stage, 
the MWiki vs [any other wiki] issue.


MWiki is the biggest source of information about the project; while its 
content is often outdated, it's still very useful. Existing links to the 
MWiki pages are in the thousands (or more). It has been updated with a 
huge effort lead by Jan, and it is now stable and reliable.


If our problem is to enlarge the administrators group for MWiki or to 
get it officially supported, I prefer to explore these options first. We 
already have three committers who can administer MWiki on the system 
administration (shell access) side, right? (jani, imacat, rbircher). How 
many more do we need? I've also just asked Infra for clarifications 
about the "supported applications" issue.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Strategic Planning: Website

[janI]

On 7 March 2013 00:43, Kay Schenk  wrote:

> On Wed, Mar 6, 2013 at 3:15 PM, janI  wrote:
>
> > On Mar 6, 2013 11:47 PM, "Kay Schenk"  wrote:
> > >
> > > On Tue, Mar 5, 2013 at 11:59 AM, janI  wrote:
> > >
> > > > On 2 March 2013 02:27, Dennis E. Hamilton 
> > wrote:
> > > >
> > > > > Right, thanks.  I talk to Ward (Cunningham) practically every week,
> > and I
> > > > > still confuse his name with Ward Christensen when typing it in
> text.
> > > > >  Christensen was a well-known CPM-80 open-source contributor from
> the
> > > > > 1980s.  (In his day job, he was an IBM tech rep.)
> > > > >
> > > > >  - Dennis
> > > > >
> > > > > -Original Message-
> > > > > From: Joseph Schaefer [mailto:joe_schae...@yahoo.com]
> > > > > Sent: Friday, March 01, 2013 16:40
> > > > > To: dev@openoffice.apache.org; orc...@apache.org
> > > > > Subject: Re: Strategic Planning: Website
> > > > >
> > > > > His last name is Cunningham, not Christensen, and I enjoyed his bar
> > camp
> > > > > talk quite a bit at this year's Apachecon.
> > > > > Pity the AOO contingent was small this time round.
> > > > >
> > > > > On Mar 1, 2013, at 4:34 PM, Dennis E. Hamilton 
> > > > wrote:
> > > > >
> > > > > > I don't think entropy is the proper term.
> > > > > >
> > > > > > The physicists version that I learned was in the following form:
> > > > > >
> > > > > > 1. You can't win.
> > > > > > 2. You can't even break even.
> > > > > > 3. And you can't get out of the game.
> > > > > >
> > > > > > I think an appropriate concern, here, has to do with technical
> > debt.
> > > > >  The longer the technical debt goes unpaid, the more interest must
> be
> > > > paid
> > > > > by someone (often the users).
> > > > > >
> > > > > > The term was introduced by Ward Christensen (inventor of the
> Wiki,
> > > > among
> > > > > other things).  Martin Fowler has a nice perspective that
> > discriminates
> > > > the
> > > > > different ways that technical debt arises (including, "if it was
> > known
> > > > then
> > > > > what is known now ... ."
> > > > > > See <http://martinfowler.com/bliki/TechnicalDebt.html>
> > > > > > and <http://martinfowler.com/bliki/TechnicalDebtQuadrant.html>.
> > > > > >
> > > > > > - Dennis
> > > > > >
> > > > > >
> > > > > >
> > > > > > -Original Message-
> > > > > > From: Donald Whytock [mailto:dwhyt...@gmail.com]
> > > > > > Sent: Friday, March 01, 2013 08:16
> > > > > > To: dev@openoffice.apache.org
> > > > > > Subject: Re: Strategic Planning: Website
> > > > > >
> > > > > > On Fri, Mar 1, 2013 at 10:19 AM, Rob Weir 
> > wrote:
> > > > > >> I'd love to hear your thoughts, and see your improvements or
> > > > > corrections.
> > > > > >
> > > > > > "Entropy.  The longer we go without solving some of the above
> > problems
> > > > > > the worse things will get."
> > > > > >
> > > > > > I'd like to see a slightly-less-apocalyptic wording for this, in
> > light
> > > > > > of the public exposure and scrutiny AOO seems to receive.
>  Perhaps:
> > > > > >
> > > > > > "Entropy.  Letting problems persist is easy, and gets easier the
> > > > > > longer it's allowed to happen.  We need to be proactive in not
> only
> > > > > > recognizing the problems, but also working to solve them."
> > > > > >
> > > > > > Don
> > > > > >
> > > > >
> > > > > I am not sure if this should go into the document or just be an
> > > > information in here:
> > > >
> > > > I have had a look at the 2 wikis supported by infra. If we want to
> move
> > > &g

RE: Strategic Planning: Website

[Dennis E. Hamilton]

Are list threads and Community Wiki topics being confused?

-Original Message-
From: Kay Schenk [mailto:kay.sch...@gmail.com] 
Sent: Wednesday, March 06, 2013 15:44
To: dev@openoffice.apache.org
Subject: Re: Strategic Planning: Website

On Wed, Mar 6, 2013 at 3:15 PM, janI  wrote:

> On Mar 6, 2013 11:47 PM, "Kay Schenk"  wrote:
[ ... ]
> > Would you be willing to start a new thread on Moin with what you know
> about
> > it -- pros, cons, conversion from Mwiki, etc. And/or add comments to:
> we already have this thread and the mwiki thread, I dont really see a need
> for other threads.
>
> rgds
> jan
>

Well I do not remember a discussion about "moin" specifically. I will look.
Thanks.


> >
> >
> https://cwiki.apache.org/confluence/display/OOOUSERS/Website+Strategic+Plan
> >
> > with what you know/suggest.
> >
> >
> > --
> >
>
> 
> > MzK
> >
> > "Achieving happiness requires the right combination of Zen and Zin."
>



-- 

MzK

"Achieving happiness requires the right combination of Zen and Zin."


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: Strategic Planning: Website

[Dennis E. Hamilton]

Um, I definitely would not recommend Moin over MWiki.

I didn't realize Moin had significant infra support, concerning the amount of 
movement to the ASF CMS.

I look forward to seeing what the pros and cons are.  

 - Dennis

-Original Message-
From: Kay Schenk [mailto:kay.sch...@gmail.com] 
Sent: Wednesday, March 06, 2013 14:47
To: dev@openoffice.apache.org
Subject: Re: Strategic Planning: Website

On Tue, Mar 5, 2013 at 11:59 AM, janI  wrote:

[ ... ]
>
> I have had a look at the 2 wikis supported by infra. If we want to move
> away from mwiki, I think it would be relatively easy to move all content to
> moin, where as cwiki would be very hard (too limited). Of course if we
> moved someone should make a fresh layout (which is possible, since setup
> files are pr project).
>
> Given the circumstances I would promote a move away from mwiki, in order to
> move forward.
>
> Jan I.
>

Jan --

I'm assuming you mention this because of this statement (on the Website
Strategic Plan page) :

"Sustainability concerns due to our use of unsupported applications (from
Apache Infra perspective), including phpBB and MWiki and reliance on a very
small number of system admins."

Would you be willing to start a new thread on Moin with what you know about
it -- pros, cons, conversion from Mwiki, etc. And/or add comments to:

https://cwiki.apache.org/confluence/display/OOOUSERS/Website+Strategic+Plan

with what you know/suggest.


-- 

MzK

"Achieving happiness requires the right combination of Zen and Zin."


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: Strategic Planning: Website

[Dennis E. Hamilton]

+1

-Original Message-
From: Rob Weir [mailto:robw...@apache.org] 
Sent: Wednesday, March 06, 2013 14:53
To: dev@openoffice.apache.org
Subject: Re: Strategic Planning: Website

[ ... ]

And let's not forget alternative ways of addressing this concern:

1) Work with Infra to make MWiki be officially supported.

or

2) Form our own admin group, with dedicated list (and private list)
and work toward developing the desired level of skill backup and
redundancy.

Maybe 2 leads eventually to 1?

-Rob


>
> --
> 
> MzK
>
> "Achieving happiness requires the right combination of Zen and Zin."

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Strategic Planning: Website

[Kay Schenk]

On Wed, Mar 6, 2013 at 3:15 PM, janI  wrote:

> On Mar 6, 2013 11:47 PM, "Kay Schenk"  wrote:
> >
> > On Tue, Mar 5, 2013 at 11:59 AM, janI  wrote:
> >
> > > On 2 March 2013 02:27, Dennis E. Hamilton 
> wrote:
> > >
> > > > Right, thanks.  I talk to Ward (Cunningham) practically every week,
> and I
> > > > still confuse his name with Ward Christensen when typing it in text.
> > > >  Christensen was a well-known CPM-80 open-source contributor from the
> > > > 1980s.  (In his day job, he was an IBM tech rep.)
> > > >
> > > >  - Dennis
> > > >
> > > > -Original Message-
> > > > From: Joseph Schaefer [mailto:joe_schae...@yahoo.com]
> > > > Sent: Friday, March 01, 2013 16:40
> > > > To: dev@openoffice.apache.org; orc...@apache.org
> > > > Subject: Re: Strategic Planning: Website
> > > >
> > > > His last name is Cunningham, not Christensen, and I enjoyed his bar
> camp
> > > > talk quite a bit at this year's Apachecon.
> > > > Pity the AOO contingent was small this time round.
> > > >
> > > > On Mar 1, 2013, at 4:34 PM, Dennis E. Hamilton 
> > > wrote:
> > > >
> > > > > I don't think entropy is the proper term.
> > > > >
> > > > > The physicists version that I learned was in the following form:
> > > > >
> > > > > 1. You can't win.
> > > > > 2. You can't even break even.
> > > > > 3. And you can't get out of the game.
> > > > >
> > > > > I think an appropriate concern, here, has to do with technical
> debt.
> > > >  The longer the technical debt goes unpaid, the more interest must be
> > > paid
> > > > by someone (often the users).
> > > > >
> > > > > The term was introduced by Ward Christensen (inventor of the Wiki,
> > > among
> > > > other things).  Martin Fowler has a nice perspective that
> discriminates
> > > the
> > > > different ways that technical debt arises (including, "if it was
> known
> > > then
> > > > what is known now ... ."
> > > > > See <http://martinfowler.com/bliki/TechnicalDebt.html>
> > > > > and <http://martinfowler.com/bliki/TechnicalDebtQuadrant.html>.
> > > > >
> > > > > - Dennis
> > > > >
> > > > >
> > > > >
> > > > > -Original Message-
> > > > > From: Donald Whytock [mailto:dwhyt...@gmail.com]
> > > > > Sent: Friday, March 01, 2013 08:16
> > > > > To: dev@openoffice.apache.org
> > > > > Subject: Re: Strategic Planning: Website
> > > > >
> > > > > On Fri, Mar 1, 2013 at 10:19 AM, Rob Weir 
> wrote:
> > > > >> I'd love to hear your thoughts, and see your improvements or
> > > > corrections.
> > > > >
> > > > > "Entropy.  The longer we go without solving some of the above
> problems
> > > > > the worse things will get."
> > > > >
> > > > > I'd like to see a slightly-less-apocalyptic wording for this, in
> light
> > > > > of the public exposure and scrutiny AOO seems to receive.  Perhaps:
> > > > >
> > > > > "Entropy.  Letting problems persist is easy, and gets easier the
> > > > > longer it's allowed to happen.  We need to be proactive in not only
> > > > > recognizing the problems, but also working to solve them."
> > > > >
> > > > > Don
> > > > >
> > > >
> > > > I am not sure if this should go into the document or just be an
> > > information in here:
> > >
> > > I have had a look at the 2 wikis supported by infra. If we want to move
> > > away from mwiki, I think it would be relatively easy to move all
> content to
> > > moin, where as cwiki would be very hard (too limited). Of course if we
> > > moved someone should make a fresh layout (which is possible, since
> setup
> > > files are pr project).
> > >
> > > Given the circumstances I would promote a move away from mwiki, in
> order to
> > > move forward.
> > >
> > > Jan I.
> > >
> >
> > Jan --
> >
> > I'm assuming you mention this because of this statement (on the Website
> > Strategic Plan page) :
> yes, and the discussion in the mwiki thread about support.
> >
> > "Sustainability concerns due to our use of unsupported applications (from
> > Apache Infra perspective), including phpBB and MWiki and reliance on a
> very
> > small number of system admins."
> >
> > Would you be willing to start a new thread on Moin with what you know
> about
> > it -- pros, cons, conversion from Mwiki, etc. And/or add comments to:
> we already have this thread and the mwiki thread, I dont really see a need
> for other threads.
>
> rgds
> jan
>

Well I do not remember a discussion about "moin" specifically. I will look.
Thanks.


> >
> >
> https://cwiki.apache.org/confluence/display/OOOUSERS/Website+Strategic+Plan
> >
> > with what you know/suggest.
> >
> >
> > --
> >
>
> 
> > MzK
> >
> > "Achieving happiness requires the right combination of Zen and Zin."
>



-- 

MzK

"Achieving happiness requires the right combination of Zen and Zin."

Re: Strategic Planning: Website

[janI]

On Mar 6, 2013 11:47 PM, "Kay Schenk"  wrote:
>
> On Tue, Mar 5, 2013 at 11:59 AM, janI  wrote:
>
> > On 2 March 2013 02:27, Dennis E. Hamilton 
wrote:
> >
> > > Right, thanks.  I talk to Ward (Cunningham) practically every week,
and I
> > > still confuse his name with Ward Christensen when typing it in text.
> > >  Christensen was a well-known CPM-80 open-source contributor from the
> > > 1980s.  (In his day job, he was an IBM tech rep.)
> > >
> > >  - Dennis
> > >
> > > -Original Message-
> > > From: Joseph Schaefer [mailto:joe_schae...@yahoo.com]
> > > Sent: Friday, March 01, 2013 16:40
> > > To: dev@openoffice.apache.org; orc...@apache.org
> > > Subject: Re: Strategic Planning: Website
> > >
> > > His last name is Cunningham, not Christensen, and I enjoyed his bar
camp
> > > talk quite a bit at this year's Apachecon.
> > > Pity the AOO contingent was small this time round.
> > >
> > > On Mar 1, 2013, at 4:34 PM, Dennis E. Hamilton 
> > wrote:
> > >
> > > > I don't think entropy is the proper term.
> > > >
> > > > The physicists version that I learned was in the following form:
> > > >
> > > > 1. You can't win.
> > > > 2. You can't even break even.
> > > > 3. And you can't get out of the game.
> > > >
> > > > I think an appropriate concern, here, has to do with technical debt.
> > >  The longer the technical debt goes unpaid, the more interest must be
> > paid
> > > by someone (often the users).
> > > >
> > > > The term was introduced by Ward Christensen (inventor of the Wiki,
> > among
> > > other things).  Martin Fowler has a nice perspective that
discriminates
> > the
> > > different ways that technical debt arises (including, "if it was known
> > then
> > > what is known now ... ."
> > > > See <http://martinfowler.com/bliki/TechnicalDebt.html>
> > > > and <http://martinfowler.com/bliki/TechnicalDebtQuadrant.html>.
> > > >
> > > > - Dennis
> > > >
> > > >
> > > >
> > > > -Original Message-
> > > > From: Donald Whytock [mailto:dwhyt...@gmail.com]
> > > > Sent: Friday, March 01, 2013 08:16
> > > > To: dev@openoffice.apache.org
> > > > Subject: Re: Strategic Planning: Website
> > > >
> > > > On Fri, Mar 1, 2013 at 10:19 AM, Rob Weir 
wrote:
> > > >> I'd love to hear your thoughts, and see your improvements or
> > > corrections.
> > > >
> > > > "Entropy.  The longer we go without solving some of the above
problems
> > > > the worse things will get."
> > > >
> > > > I'd like to see a slightly-less-apocalyptic wording for this, in
light
> > > > of the public exposure and scrutiny AOO seems to receive.  Perhaps:
> > > >
> > > > "Entropy.  Letting problems persist is easy, and gets easier the
> > > > longer it's allowed to happen.  We need to be proactive in not only
> > > > recognizing the problems, but also working to solve them."
> > > >
> > > > Don
> > > >
> > >
> > > I am not sure if this should go into the document or just be an
> > information in here:
> >
> > I have had a look at the 2 wikis supported by infra. If we want to move
> > away from mwiki, I think it would be relatively easy to move all
content to
> > moin, where as cwiki would be very hard (too limited). Of course if we
> > moved someone should make a fresh layout (which is possible, since setup
> > files are pr project).
> >
> > Given the circumstances I would promote a move away from mwiki, in
order to
> > move forward.
> >
> > Jan I.
> >
>
> Jan --
>
> I'm assuming you mention this because of this statement (on the Website
> Strategic Plan page) :
yes, and the discussion in the mwiki thread about support.
>
> "Sustainability concerns due to our use of unsupported applications (from
> Apache Infra perspective), including phpBB and MWiki and reliance on a
very
> small number of system admins."
>
> Would you be willing to start a new thread on Moin with what you know
about
> it -- pros, cons, conversion from Mwiki, etc. And/or add comments to:
we already have this thread and the mwiki thread, I dont really see a need
for other threads.

rgds
jan
>
>
https://cwiki.apache.org/confluence/display/OOOUSERS/Website+Strategic+Plan
>
> with what you know/suggest.
>
>
> --
>

> MzK
>
> "Achieving happiness requires the right combination of Zen and Zin."

Re: Strategic Planning: Website

[Rob Weir]

On Wed, Mar 6, 2013 at 5:46 PM, Kay Schenk  wrote:
> On Tue, Mar 5, 2013 at 11:59 AM, janI  wrote:
>
>> On 2 March 2013 02:27, Dennis E. Hamilton  wrote:
>>
>> > Right, thanks.  I talk to Ward (Cunningham) practically every week, and I
>> > still confuse his name with Ward Christensen when typing it in text.
>> >  Christensen was a well-known CPM-80 open-source contributor from the
>> > 1980s.  (In his day job, he was an IBM tech rep.)
>> >
>> >  - Dennis
>> >
>> > -Original Message-
>> > From: Joseph Schaefer [mailto:joe_schae...@yahoo.com]
>> > Sent: Friday, March 01, 2013 16:40
>> > To: dev@openoffice.apache.org; orc...@apache.org
>> > Subject: Re: Strategic Planning: Website
>> >
>> > His last name is Cunningham, not Christensen, and I enjoyed his bar camp
>> > talk quite a bit at this year's Apachecon.
>> > Pity the AOO contingent was small this time round.
>> >
>> > On Mar 1, 2013, at 4:34 PM, Dennis E. Hamilton 
>> wrote:
>> >
>> > > I don't think entropy is the proper term.
>> > >
>> > > The physicists version that I learned was in the following form:
>> > >
>> > > 1. You can't win.
>> > > 2. You can't even break even.
>> > > 3. And you can't get out of the game.
>> > >
>> > > I think an appropriate concern, here, has to do with technical debt.
>> >  The longer the technical debt goes unpaid, the more interest must be
>> paid
>> > by someone (often the users).
>> > >
>> > > The term was introduced by Ward Christensen (inventor of the Wiki,
>> among
>> > other things).  Martin Fowler has a nice perspective that discriminates
>> the
>> > different ways that technical debt arises (including, "if it was known
>> then
>> > what is known now ... ."
>> > > See <http://martinfowler.com/bliki/TechnicalDebt.html>
>> > > and <http://martinfowler.com/bliki/TechnicalDebtQuadrant.html>.
>> > >
>> > > - Dennis
>> > >
>> > >
>> > >
>> > > -Original Message-
>> > > From: Donald Whytock [mailto:dwhyt...@gmail.com]
>> > > Sent: Friday, March 01, 2013 08:16
>> > > To: dev@openoffice.apache.org
>> > > Subject: Re: Strategic Planning: Website
>> > >
>> > > On Fri, Mar 1, 2013 at 10:19 AM, Rob Weir  wrote:
>> > >> I'd love to hear your thoughts, and see your improvements or
>> > corrections.
>> > >
>> > > "Entropy.  The longer we go without solving some of the above problems
>> > > the worse things will get."
>> > >
>> > > I'd like to see a slightly-less-apocalyptic wording for this, in light
>> > > of the public exposure and scrutiny AOO seems to receive.  Perhaps:
>> > >
>> > > "Entropy.  Letting problems persist is easy, and gets easier the
>> > > longer it's allowed to happen.  We need to be proactive in not only
>> > > recognizing the problems, but also working to solve them."
>> > >
>> > > Don
>> > >
>> >
>> > I am not sure if this should go into the document or just be an
>> information in here:
>>
>> I have had a look at the 2 wikis supported by infra. If we want to move
>> away from mwiki, I think it would be relatively easy to move all content to
>> moin, where as cwiki would be very hard (too limited). Of course if we
>> moved someone should make a fresh layout (which is possible, since setup
>> files are pr project).
>>
>> Given the circumstances I would promote a move away from mwiki, in order to
>> move forward.
>>
>> Jan I.
>>
>
> Jan --
>
> I'm assuming you mention this because of this statement (on the Website
> Strategic Plan page) :
>
> "Sustainability concerns due to our use of unsupported applications (from
> Apache Infra perspective), including phpBB and MWiki and reliance on a very
> small number of system admins."
>
> Would you be willing to start a new thread on Moin with what you know about
> it -- pros, cons, conversion from Mwiki, etc. And/or add comments to:
>
> https://cwiki.apache.org/confluence/display/OOOUSERS/Website+Strategic+Plan
>
> with what you know/suggest.
>

And let's not forget alternative ways of addressing this concern:

1) Work with Infra to make MWiki be officially supported.

or

2) Form our own admin group, with dedicated list (and private list)
and work toward developing the desired level of skill backup and
redundancy.

Maybe 2 leads eventually to 1?

-Rob


>
> --
> 
> MzK
>
> "Achieving happiness requires the right combination of Zen and Zin."

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Strategic Planning: Website

[Kay Schenk]

On Tue, Mar 5, 2013 at 11:59 AM, janI  wrote:

> On 2 March 2013 02:27, Dennis E. Hamilton  wrote:
>
> > Right, thanks.  I talk to Ward (Cunningham) practically every week, and I
> > still confuse his name with Ward Christensen when typing it in text.
> >  Christensen was a well-known CPM-80 open-source contributor from the
> > 1980s.  (In his day job, he was an IBM tech rep.)
> >
> >  - Dennis
> >
> > -Original Message-
> > From: Joseph Schaefer [mailto:joe_schae...@yahoo.com]
> > Sent: Friday, March 01, 2013 16:40
> > To: dev@openoffice.apache.org; orc...@apache.org
> > Subject: Re: Strategic Planning: Website
> >
> > His last name is Cunningham, not Christensen, and I enjoyed his bar camp
> > talk quite a bit at this year's Apachecon.
> > Pity the AOO contingent was small this time round.
> >
> > On Mar 1, 2013, at 4:34 PM, Dennis E. Hamilton 
> wrote:
> >
> > > I don't think entropy is the proper term.
> > >
> > > The physicists version that I learned was in the following form:
> > >
> > > 1. You can't win.
> > > 2. You can't even break even.
> > > 3. And you can't get out of the game.
> > >
> > > I think an appropriate concern, here, has to do with technical debt.
> >  The longer the technical debt goes unpaid, the more interest must be
> paid
> > by someone (often the users).
> > >
> > > The term was introduced by Ward Christensen (inventor of the Wiki,
> among
> > other things).  Martin Fowler has a nice perspective that discriminates
> the
> > different ways that technical debt arises (including, "if it was known
> then
> > what is known now ... ."
> > > See <http://martinfowler.com/bliki/TechnicalDebt.html>
> > > and <http://martinfowler.com/bliki/TechnicalDebtQuadrant.html>.
> > >
> > > - Dennis
> > >
> > >
> > >
> > > -Original Message-
> > > From: Donald Whytock [mailto:dwhyt...@gmail.com]
> > > Sent: Friday, March 01, 2013 08:16
> > > To: dev@openoffice.apache.org
> > > Subject: Re: Strategic Planning: Website
> > >
> > > On Fri, Mar 1, 2013 at 10:19 AM, Rob Weir  wrote:
> > >> I'd love to hear your thoughts, and see your improvements or
> > corrections.
> > >
> > > "Entropy.  The longer we go without solving some of the above problems
> > > the worse things will get."
> > >
> > > I'd like to see a slightly-less-apocalyptic wording for this, in light
> > > of the public exposure and scrutiny AOO seems to receive.  Perhaps:
> > >
> > > "Entropy.  Letting problems persist is easy, and gets easier the
> > > longer it's allowed to happen.  We need to be proactive in not only
> > > recognizing the problems, but also working to solve them."
> > >
> > > Don
> > >
> >
> > I am not sure if this should go into the document or just be an
> information in here:
>
> I have had a look at the 2 wikis supported by infra. If we want to move
> away from mwiki, I think it would be relatively easy to move all content to
> moin, where as cwiki would be very hard (too limited). Of course if we
> moved someone should make a fresh layout (which is possible, since setup
> files are pr project).
>
> Given the circumstances I would promote a move away from mwiki, in order to
> move forward.
>
> Jan I.
>

Jan --

I'm assuming you mention this because of this statement (on the Website
Strategic Plan page) :

"Sustainability concerns due to our use of unsupported applications (from
Apache Infra perspective), including phpBB and MWiki and reliance on a very
small number of system admins."

Would you be willing to start a new thread on Moin with what you know about
it -- pros, cons, conversion from Mwiki, etc. And/or add comments to:

https://cwiki.apache.org/confluence/display/OOOUSERS/Website+Strategic+Plan

with what you know/suggest.


-- 

MzK

"Achieving happiness requires the right combination of Zen and Zin."

Re: Strategic Planning: Website

[janI]

On 2 March 2013 02:27, Dennis E. Hamilton  wrote:

> Right, thanks.  I talk to Ward (Cunningham) practically every week, and I
> still confuse his name with Ward Christensen when typing it in text.
>  Christensen was a well-known CPM-80 open-source contributor from the
> 1980s.  (In his day job, he was an IBM tech rep.)
>
>  - Dennis
>
> -Original Message-
> From: Joseph Schaefer [mailto:joe_schae...@yahoo.com]
> Sent: Friday, March 01, 2013 16:40
> To: dev@openoffice.apache.org; orc...@apache.org
> Subject: Re: Strategic Planning: Website
>
> His last name is Cunningham, not Christensen, and I enjoyed his bar camp
> talk quite a bit at this year's Apachecon.
> Pity the AOO contingent was small this time round.
>
> On Mar 1, 2013, at 4:34 PM, Dennis E. Hamilton  wrote:
>
> > I don't think entropy is the proper term.
> >
> > The physicists version that I learned was in the following form:
> >
> > 1. You can't win.
> > 2. You can't even break even.
> > 3. And you can't get out of the game.
> >
> > I think an appropriate concern, here, has to do with technical debt.
>  The longer the technical debt goes unpaid, the more interest must be paid
> by someone (often the users).
> >
> > The term was introduced by Ward Christensen (inventor of the Wiki, among
> other things).  Martin Fowler has a nice perspective that discriminates the
> different ways that technical debt arises (including, "if it was known then
> what is known now ... ."
> > See <http://martinfowler.com/bliki/TechnicalDebt.html>
> > and <http://martinfowler.com/bliki/TechnicalDebtQuadrant.html>.
> >
> > - Dennis
> >
> >
> >
> > -Original Message-
> > From: Donald Whytock [mailto:dwhyt...@gmail.com]
> > Sent: Friday, March 01, 2013 08:16
> > To: dev@openoffice.apache.org
> > Subject: Re: Strategic Planning: Website
> >
> > On Fri, Mar 1, 2013 at 10:19 AM, Rob Weir  wrote:
> >> I'd love to hear your thoughts, and see your improvements or
> corrections.
> >
> > "Entropy.  The longer we go without solving some of the above problems
> > the worse things will get."
> >
> > I'd like to see a slightly-less-apocalyptic wording for this, in light
> > of the public exposure and scrutiny AOO seems to receive.  Perhaps:
> >
> > "Entropy.  Letting problems persist is easy, and gets easier the
> > longer it's allowed to happen.  We need to be proactive in not only
> > recognizing the problems, but also working to solve them."
> >
> > Don
> >
>
> I am not sure if this should go into the document or just be an
information in here:

I have had a look at the 2 wikis supported by infra. If we want to move
away from mwiki, I think it would be relatively easy to move all content to
moin, where as cwiki would be very hard (too limited). Of course if we
moved someone should make a fresh layout (which is possible, since setup
files are pr project).

Given the circumstances I would promote a move away from mwiki, in order to
move forward.

Jan I.

RE: Strategic Planning: Website

[Dennis E. Hamilton]

Right, thanks.  I talk to Ward (Cunningham) practically every week, and I still 
confuse his name with Ward Christensen when typing it in text.  Christensen was 
a well-known CPM-80 open-source contributor from the 1980s.  (In his day job, 
he was an IBM tech rep.)

 - Dennis

-Original Message-
From: Joseph Schaefer [mailto:joe_schae...@yahoo.com] 
Sent: Friday, March 01, 2013 16:40
To: dev@openoffice.apache.org; orc...@apache.org
Subject: Re: Strategic Planning: Website

His last name is Cunningham, not Christensen, and I enjoyed his bar camp talk 
quite a bit at this year's Apachecon.
Pity the AOO contingent was small this time round.

On Mar 1, 2013, at 4:34 PM, Dennis E. Hamilton  wrote:

> I don't think entropy is the proper term.
> 
> The physicists version that I learned was in the following form:
> 
> 1. You can't win.
> 2. You can't even break even.
> 3. And you can't get out of the game.
> 
> I think an appropriate concern, here, has to do with technical debt.  The 
> longer the technical debt goes unpaid, the more interest must be paid by 
> someone (often the users).
> 
> The term was introduced by Ward Christensen (inventor of the Wiki, among 
> other things).  Martin Fowler has a nice perspective that discriminates the 
> different ways that technical debt arises (including, "if it was known then 
> what is known now ... ."
> See <http://martinfowler.com/bliki/TechnicalDebt.html>
> and <http://martinfowler.com/bliki/TechnicalDebtQuadrant.html>.
> 
> - Dennis
> 
> 
> 
> -Original Message-
> From: Donald Whytock [mailto:dwhyt...@gmail.com] 
> Sent: Friday, March 01, 2013 08:16
> To: dev@openoffice.apache.org
> Subject: Re: Strategic Planning: Website
> 
> On Fri, Mar 1, 2013 at 10:19 AM, Rob Weir  wrote:
>> I'd love to hear your thoughts, and see your improvements or corrections.
> 
> "Entropy.  The longer we go without solving some of the above problems
> the worse things will get."
> 
> I'd like to see a slightly-less-apocalyptic wording for this, in light
> of the public exposure and scrutiny AOO seems to receive.  Perhaps:
> 
> "Entropy.  Letting problems persist is easy, and gets easier the
> longer it's allowed to happen.  We need to be proactive in not only
> recognizing the problems, but also working to solve them."
> 
> Don
> 

Re: Strategic Planning: Website

[Rob Weir]

On Fri, Mar 1, 2013 at 7:34 PM, Dennis E. Hamilton  wrote:
> I don't think entropy is the proper term.
>
> The physicists version that I learned was in the following form:
>
>  1. You can't win.
>  2. You can't even break even.
>  3. And you can't get out of the game.
>
> I think an appropriate concern, here, has to do with technical debt.  The 
> longer the technical debt goes unpaid, the more interest must be paid by 
> someone (often the users).
>

There may be technical debt as well, but I was thinking specifically
of entropy, the increase in disorder.  For example, you can see a
steady increase in the number of broken incoming links to our website.

-Rob

> The term was introduced by Ward Christensen (inventor of the Wiki, among 
> other things).  Martin Fowler has a nice perspective that discriminates the 
> different ways that technical debt arises (including, "if it was known then 
> what is known now ... ."
> See <http://martinfowler.com/bliki/TechnicalDebt.html>
> and <http://martinfowler.com/bliki/TechnicalDebtQuadrant.html>.
>
>  - Dennis
>
>
>
> -Original Message-
> From: Donald Whytock [mailto:dwhyt...@gmail.com]
> Sent: Friday, March 01, 2013 08:16
> To: dev@openoffice.apache.org
> Subject: Re: Strategic Planning: Website
>
> On Fri, Mar 1, 2013 at 10:19 AM, Rob Weir  wrote:
>> I'd love to hear your thoughts, and see your improvements or corrections.
>
> "Entropy.  The longer we go without solving some of the above problems
> the worse things will get."
>
> I'd like to see a slightly-less-apocalyptic wording for this, in light
> of the public exposure and scrutiny AOO seems to receive.  Perhaps:
>
> "Entropy.  Letting problems persist is easy, and gets easier the
> longer it's allowed to happen.  We need to be proactive in not only
> recognizing the problems, but also working to solve them."
>
> Don
>

Re: Strategic Planning: Website

[Joseph Schaefer]

His last name is Cunningham, not Christensen, and I enjoyed his bar camp talk 
quite a bit at this year's Apachecon.
Pity the AOO contingent was small this time round.

On Mar 1, 2013, at 4:34 PM, Dennis E. Hamilton  wrote:

> I don't think entropy is the proper term.
> 
> The physicists version that I learned was in the following form:
> 
> 1. You can't win.
> 2. You can't even break even.
> 3. And you can't get out of the game.
> 
> I think an appropriate concern, here, has to do with technical debt.  The 
> longer the technical debt goes unpaid, the more interest must be paid by 
> someone (often the users).
> 
> The term was introduced by Ward Christensen (inventor of the Wiki, among 
> other things).  Martin Fowler has a nice perspective that discriminates the 
> different ways that technical debt arises (including, "if it was known then 
> what is known now ... ."
> See <http://martinfowler.com/bliki/TechnicalDebt.html>
> and <http://martinfowler.com/bliki/TechnicalDebtQuadrant.html>.
> 
> - Dennis
> 
> 
> 
> -Original Message-
> From: Donald Whytock [mailto:dwhyt...@gmail.com] 
> Sent: Friday, March 01, 2013 08:16
> To: dev@openoffice.apache.org
> Subject: Re: Strategic Planning: Website
> 
> On Fri, Mar 1, 2013 at 10:19 AM, Rob Weir  wrote:
>> I'd love to hear your thoughts, and see your improvements or corrections.
> 
> "Entropy.  The longer we go without solving some of the above problems
> the worse things will get."
> 
> I'd like to see a slightly-less-apocalyptic wording for this, in light
> of the public exposure and scrutiny AOO seems to receive.  Perhaps:
> 
> "Entropy.  Letting problems persist is easy, and gets easier the
> longer it's allowed to happen.  We need to be proactive in not only
> recognizing the problems, but also working to solve them."
> 
> Don
> 

RE: Strategic Planning: Website

[Dennis E. Hamilton]

I don't think entropy is the proper term.

The physicists version that I learned was in the following form:

 1. You can't win.
 2. You can't even break even.
 3. And you can't get out of the game.

I think an appropriate concern, here, has to do with technical debt.  The 
longer the technical debt goes unpaid, the more interest must be paid by 
someone (often the users).

The term was introduced by Ward Christensen (inventor of the Wiki, among other 
things).  Martin Fowler has a nice perspective that discriminates the different 
ways that technical debt arises (including, "if it was known then what is known 
now ... ."
See <http://martinfowler.com/bliki/TechnicalDebt.html>
and <http://martinfowler.com/bliki/TechnicalDebtQuadrant.html>.

 - Dennis



-Original Message-
From: Donald Whytock [mailto:dwhyt...@gmail.com] 
Sent: Friday, March 01, 2013 08:16
To: dev@openoffice.apache.org
Subject: Re: Strategic Planning: Website

On Fri, Mar 1, 2013 at 10:19 AM, Rob Weir  wrote:
> I'd love to hear your thoughts, and see your improvements or corrections.

"Entropy.  The longer we go without solving some of the above problems
the worse things will get."

I'd like to see a slightly-less-apocalyptic wording for this, in light
of the public exposure and scrutiny AOO seems to receive.  Perhaps:

"Entropy.  Letting problems persist is easy, and gets easier the
longer it's allowed to happen.  We need to be proactive in not only
recognizing the problems, but also working to solve them."

Don

Re: Strategic Planning: Website

[Rob Weir]

On Fri, Mar 1, 2013 at 11:16 AM, Donald Whytock  wrote:
> On Fri, Mar 1, 2013 at 10:19 AM, Rob Weir  wrote:
>> I'd love to hear your thoughts, and see your improvements or corrections.
>
> "Entropy.  The longer we go without solving some of the above problems
> the worse things will get."
>
> I'd like to see a slightly-less-apocalyptic wording for this, in light
> of the public exposure and scrutiny AOO seems to receive.  Perhaps:
>
> "Entropy.  Letting problems persist is easy, and gets easier the
> longer it's allowed to happen.  We need to be proactive in not only
> recognizing the problems, but also working to solve them."
>

I took that section out altogether.  It seemed like a good section,
but I haven't really found anything to say there that is not just a
repetition of matters already discussed in the earlier sections.

-Rob

> Don

Re: Strategic Planning: Website

[Kay Schenk]

On Fri, Mar 1, 2013 at 7:19 AM, Rob Weir  wrote:

> I apologize in advance for talking like a corporation.  But I think
> there is some good things we can borrow from corporate thinking, and
> one is to discuss and adopt long-term strategic plans.  The danger of
> not doing this is that continually focus on what is immediately in
> front of our eyes, working on short-term, urgent activities, but never
> accomplish the grand things that can only be done with a big effort
> over time.
>
> To me a strategic plan means we look at where things are today, what
> works, what doesn't.  Then we step back and ask ourselves what our
> goals should be over the next few years.  Maybe even the next year.
> But generally, thinking long-term, beyond the next release, beyond the
> activities that we already have on our plates.
>
> Developing a shared vision for where we want to go is critical to
> long-term success.
>
> As an example, I drafted some ideas on our websites and the challenges
> and opportunities there:
>
> https://cwiki.apache.org/confluence/display/OOOUSERS/Website+Strategic+Plan
>
> I'd love to hear your thoughts, and see your improvements or corrections.
>
> I'd also encourage anyone who has an interest to draft a similar
> strategic plan for other areas, such as the AOO product itself,
> Documentation, Development process/Build, Marketing, etc.  Note: part
> of this is being honest about what is not working well, as what is
> working well.  So please be critical, but constructive.
>
> Regards,
>
> -Rob
>

Rob, yes I saw the commit notices about this, and GOOD IDEA!

This is no corporate speak to me but, given OpenOffice's history, just good
sense.  I will happily add some items when I get time over the next few
days. We definitely need a "code/product" strategic plan area. MANY items
concerning such things have arisen on this list over the last several
months, and using the strategic plan area is a good way to document them!

Thanks for taking the time to start this.

-- 

MzK

"Achieving happiness requires the right combination of Zen and Zin."

Re: Strategic Planning: Website

[Rob Weir]

On Fri, Mar 1, 2013 at 11:21 AM, janI  wrote:
> On 1 March 2013 16:19, Rob Weir  wrote:
>
>> I apologize in advance for talking like a corporation.  But I think
>> there is some good things we can borrow from corporate thinking, and
>> one is to discuss and adopt long-term strategic plans.  The danger of
>> not doing this is that continually focus on what is immediately in
>> front of our eyes, working on short-term, urgent activities, but never
>> accomplish the grand things that can only be done with a big effort
>> over time.
>>
>> To me a strategic plan means we look at where things are today, what
>> works, what doesn't.  Then we step back and ask ourselves what our
>> goals should be over the next few years.  Maybe even the next year.
>> But generally, thinking long-term, beyond the next release, beyond the
>> activities that we already have on our plates.
>>
>> Developing a shared vision for where we want to go is critical to
>> long-term success.
>>
>> As an example, I drafted some ideas on our websites and the challenges
>> and opportunities there:
>>
>> https://cwiki.apache.org/confluence/display/OOOUSERS/Website+Strategic+Plan
>>
>> A very good initative, I do feel however that bugzilla and svn are also
> part of of our "outside" image and should be included.
>

If you have some ideas there, go ahead and add them.  Or maybe they
would be part of a "development process" strategic plan?   There is
going to be unavoidable overlap among the plans...

> I agree discussing and developing a shared vision is a requirement for a
> long term success, but it needs to be coupled with the available resources
> and possibilities, otherwise we might come to a vision that is unrealistic.
>

I'm hoping these reinforce each other.  Having a longer-term vision
can help with recruitment as well.  Some volunteers want small
bite-sized things they can work on short term.  But others are looking
for something more exciting and substantial.   So having a few big
challenges is a good thing.  Of course, we don't want science fiction
either.  I did avoid talking about the "semantic web" ;-)

-Rob

> rgds
> Jan I.
>
>> I'd love to hear your thoughts, and see your improvements or corrections.
>>
>> I'd also encourage anyone who has an interest to draft a similar
>> strategic plan for other areas, such as the AOO product itself,
>> Documentation, Development process/Build, Marketing, etc.  Note: part
>> of this is being honest about what is not working well, as what is
>> working well.  So please be critical, but constructive.
>>
>
> Regards,
>>
>> -Rob
>>

 a

Re: Strategic Planning: Website

[janI]

On 1 March 2013 16:19, Rob Weir  wrote:

> I apologize in advance for talking like a corporation.  But I think
> there is some good things we can borrow from corporate thinking, and
> one is to discuss and adopt long-term strategic plans.  The danger of
> not doing this is that continually focus on what is immediately in
> front of our eyes, working on short-term, urgent activities, but never
> accomplish the grand things that can only be done with a big effort
> over time.
>
> To me a strategic plan means we look at where things are today, what
> works, what doesn't.  Then we step back and ask ourselves what our
> goals should be over the next few years.  Maybe even the next year.
> But generally, thinking long-term, beyond the next release, beyond the
> activities that we already have on our plates.
>
> Developing a shared vision for where we want to go is critical to
> long-term success.
>
> As an example, I drafted some ideas on our websites and the challenges
> and opportunities there:
>
> https://cwiki.apache.org/confluence/display/OOOUSERS/Website+Strategic+Plan
>
> A very good initative, I do feel however that bugzilla and svn are also
part of of our "outside" image and should be included.

I agree discussing and developing a shared vision is a requirement for a
long term success, but it needs to be coupled with the available resources
and possibilities, otherwise we might come to a vision that is unrealistic.

rgds
Jan I.

> I'd love to hear your thoughts, and see your improvements or corrections.
>
> I'd also encourage anyone who has an interest to draft a similar
> strategic plan for other areas, such as the AOO product itself,
> Documentation, Development process/Build, Marketing, etc.  Note: part
> of this is being honest about what is not working well, as what is
> working well.  So please be critical, but constructive.
>

Regards,
>
> -Rob
>

Re: Strategic Planning: Website

[Donald Whytock]

On Fri, Mar 1, 2013 at 10:19 AM, Rob Weir  wrote:
> I'd love to hear your thoughts, and see your improvements or corrections.

"Entropy.  The longer we go without solving some of the above problems
the worse things will get."

I'd like to see a slightly-less-apocalyptic wording for this, in light
of the public exposure and scrutiny AOO seems to receive.  Perhaps:

"Entropy.  Letting problems persist is easy, and gets easier the
longer it's allowed to happen.  We need to be proactive in not only
recognizing the problems, but also working to solve them."

Don

Strategic Planning: Website

[Rob Weir]

I apologize in advance for talking like a corporation.  But I think
there is some good things we can borrow from corporate thinking, and
one is to discuss and adopt long-term strategic plans.  The danger of
not doing this is that continually focus on what is immediately in
front of our eyes, working on short-term, urgent activities, but never
accomplish the grand things that can only be done with a big effort
over time.

To me a strategic plan means we look at where things are today, what
works, what doesn't.  Then we step back and ask ourselves what our
goals should be over the next few years.  Maybe even the next year.
But generally, thinking long-term, beyond the next release, beyond the
activities that we already have on our plates.

Developing a shared vision for where we want to go is critical to
long-term success.

As an example, I drafted some ideas on our websites and the challenges
and opportunities there:

https://cwiki.apache.org/confluence/display/OOOUSERS/Website+Strategic+Plan

I'd love to hear your thoughts, and see your improvements or corrections.

I'd also encourage anyone who has an interest to draft a similar
strategic plan for other areas, such as the AOO product itself,
Documentation, Development process/Build, Marketing, etc.  Note: part
of this is being honest about what is not working well, as what is
working well.  So please be critical, but constructive.

Regards,

-Rob