I finally nerved-up to figure out how to make the bookmarklet work in IE 9. It 
took a little effort, but I managed it.

It is an interesting way to tell that a web page was published via the CMS, or 
not.

Having looked around a little, I can understand why there are not many folks 
who have the confidence and willingness to work on the site this way.  For 
folks who want to support the project via web, wiki, and forum contributions, 
the learning curve and conceptual understanding of the workflow is daunting.  
Not having commit karma adds to that for those who might be willing to dive in 
regardless.  

For those of us who have the nerve and the karma, there remains the question of 
individual priorities and willingness to go through what it takes to become 
fluent with this particular arrangement.

There are three kinds of proficiency required: (1) fluency with the tool chain, 
(2) comprehension of the site organization and conventions with regard to its 
content, and (3) the practices that are part of the DNA of the Apache 
[OpenOffice] development community.  We don't all bring the necessary 
combination of fearlessness, willingness, and existing experience.

 - Dennis

FURTHER OBSERVATIONS

 1. I made the bookmarklet the hard way.  Even then, getting it onto my toolbar 
for easy use was not possible until I enabled the IE Favorites Bar.  That is 
not something I ordinarily use.  It is different than the full set of 
bookmarks/favorites available on the menu bar, something I continue to use by 
personal preference.  But once I enabled the IE Favorites Bar, I could drag the 
successfully-manufactured shortcut there.  Now it is handily available at the 
top of my browser window.

 2. My personal reaction is that I want to be able to use my desktop tools, 
including WYSIWYG HTML editors as well as good HTML-level text editors, to do 
any maintenance work on the site.  In-browser editing is not productive for me. 
 When I am doing substantial wiki work, I compose off-line and paste into the 
wiki editor instead of rely on the in-browser submission of wikiText.  I even 
use separate revision control systems to back up my work when I do that.  Using 
the Apache SVN and Markdown is an use-case that works, except for not being 
able to proof the result immediately.

 3. I think that means using working copies from the SVN repo in my case.  That 
makes it is easier for me to recover or repair any miss-step, and that is 
important for my contribution to any production system.

Either way, there is considerable tacit knowledge required to operate reliably 
and with confidence with this material, especially at the rather raw level at 
which much of the ooo-site content is seen.  Understanding the workflow from 
SVN to staging to production and how to operate with that is the next 
challenge.  

If I were not a committer, I would not even consider doing everything needed to 
submit a patch in order to fix a page.  

As a committer whose expertise is not with this particular setup, I might 
consider submitting a patch anyhow, since I know how easy it is to make them in 
my SVN working copy.


  





-----Original Message-----
From: Joe Schaefer [mailto:[email protected]] 
Sent: Wednesday, February 08, 2012 11:05
To: [email protected]
Subject: ANONYMOUS CMS ACCESS (was Re: Bad Link on OOO API Web Page)

I don't know if this level of participation interests you Ric,
but I'd like to share with the group the process involved in
producing an actual patch suitable for a committer to apply
regarding the website documents.

The first thing an interested party needs to do is to install
the CMS bookmarklet wherever their browser normally keeps bookmarks.
The url which describes this process is at

    https://cms.apache.org/ooo-site/#bookmark

You will be prompted for credentials when you visit that url:
non-committers should present a username of anonymous and an
empty password.  Those creds will grant you full access to
the CMS.

What you do then is go to the actual page in question:

http://www.openoffice.org/api/docs/common/ref/com/sun/star/text/module-ix.html

and simply click on the bookmarklet.  After a few moments to
prepare a working copy for you, you will be directed to the
source page containing the errant html.  Click on the [Edit]
link and an editor session will let you modify the file to
make the appropriate changes.  Submit those changes to the
server and click on the [Diff] link which will show you your
changes in patch form.  On that page is the option to [Mail Diff]
whereby you can mail your patch off to this mailing list
simply by filling out the form.

Yes it's that easy, and committers will know how to incorporate
your changes into the live site from there.


HTH



----- Original Message -----
> From: Ric Gaudet <[email protected]>
> To: [email protected]
> Cc: 
> Sent: Wednesday, February 8, 2012 1:22 PM
> Subject: Bad Link on OOO API Web Page
> 
> 
> Hi,
> 
> I found a link on this page that is bad:
> 
> 
> 
>     
>     
>     
>     
> 
> 
> http://www.openoffice.org/api/docs/common/ref/com/sun/star/text/module-ix.html
> 
> 
> 
> 
> The link is to the tag "fieldmaster" located in the "Nested 
> Modules" area
> The current link:
> 
> 
> 
>     
>     
>     
>     
> 
> 
> http://www.openoffice.org/api/docs/common/ref/com/sun/star/text/fieldmaster/module-ix.html
> 
> 
> 
> 
> should instead be:
> 
> 
> 
>     
>     
>     
>     
> 
> 
> http://www.openoffice.org/api/docs/common/ref/com/sun/star/text/FieldMaster/module-ix.html
> 
> the difference being "FieldMaster" vs. "fieldmaster".
> However, since the module's name is actually "fieldmaster", 
> perhaps the page  url containing that content should instead be lowercase. 
> I am still a beginner to Uno, so I have not yet figured out all the naming 
> conventions (or even how to navigate easily through the API!).
> Thanks,
> Ric Gaudet
> 

Reply via email to