Re: problem with javascript in contracts
Sorry for the late response guys, I've been tied up with work and school :) On Thursday 04 August 2005 2:25 am, Thorsten Scherler wrote: You need to escape the . It depends on your contract but the subject is javascript in contracts. alert(unescape(http%3A//maps.google.com/maps%3Ffile%3Dapi%26v%3D1)); Tried this, but it outputs the stuff _as is_ in the generated page (that is, I want the HTML page to contain file=apiv=1 and *not* file%3Dapi%26v%3D1. I'm doing some more tests to see if that might actually work, If you use plain xml then refer to http://www.w3.org/TR/xhtml-modularization/dtd_module_defs.html#a_xhtml_char acter_entities Is this similar to what Todd suggested? That is, I just use amp; ? Do I need to explicitly invoke the xhtml-special.ent for this? Like said by Cyriaque: can you explain us exactly what you want to do with your contract ? Pretty simple actually :) I'm just trying to make a configurable contract that will let the user include a custom google map in his/her content. The configurable parameters being the API key and the location (and later on, other things that the Google Maps API supports) Diwaker -- Web/Blog/Gallery: http://floatingsun.net pgp0a4T9QKeo1.pgp Description: PGP signature
[jira] Updated: (FOR-605) CSS enhancements needed for MOTD area inside Table of Contents
[ http://issues.apache.org/jira/browse/FOR-605?page=all ] David Crossley updated FOR-605: --- Attachment: 605-screenshot.png CSS enhancements needed for MOTD area inside Table of Contents -- Key: FOR-605 URL: http://issues.apache.org/jira/browse/FOR-605 Project: Forrest Type: Bug Versions: 0.8-dev Reporter: David Crossley Fix For: 0.8-dev Attachments: 605-screenshot.png The Message of the Day (MOTD) facility inserts a panel at the top right of the Table of Contents (ToC). However this panel interferes with the flow of text in the ToC, forcing items to be line-wrapped to a narrow width. The MOTD is not properly implemented with CSS, probably needs its own definition. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (FOR-605) CSS enhancements needed for MOTD area inside Table of Contents
CSS enhancements needed for MOTD area inside Table of Contents -- Key: FOR-605 URL: http://issues.apache.org/jira/browse/FOR-605 Project: Forrest Type: Bug Versions: 0.8-dev Reporter: David Crossley Fix For: 0.8-dev Attachments: 605-screenshot.png The Message of the Day (MOTD) facility inserts a panel at the top right of the Table of Contents (ToC). However this panel interferes with the flow of text in the ToC, forcing items to be line-wrapped to a narrow width. The MOTD is not properly implemented with CSS, probably needs its own definition. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
using forrest:property in contracts head section
Hey everyone, As my travails with the Google Maps contract continue, I came across the following problem. Consider the following snippet from this hypothetical contract: forrest:template xmlns:forrest=http://apache.org/forrest/templates/1.0; format=xhtml name=content-google-maps inputFormat=xsl body=true head=true xsl:stylesheet version=1.1 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xsl:template name=content-google-maps-head xsl:param name=content-google-maps-key/ divxsl:value-of select=$content-google-maps-key//div /xsl:template xsl:template name=content-google-maps-body xsl:param name=content-google-maps-key/ divxsl:value-of select=$content-google-maps-key//div /xsl:template /xsl:stylesheet /forrest:template And now I try to use it in my view thus: forrest:contract name=content-google-maps forrest:properties contract=content-google-maps forrest:property name=content-google-maps-keyyour-key-here/forrest:property /forrest:properties /forrest:contract In the generated output, I see in the head section: (unexpected behavior) div/div But in the body section, I see in the body section: (expected behavior) divyour-key-here/div Any idea whats going on here? Diwaker -- Web/Blog/Gallery: http://floatingsun.net pgpDYFT6N1vQf.pgp Description: PGP signature
[jira] Commented: (FOR-604) The document-v* warning element does not get rendered properly
[
http://issues.apache.org/jira/browse/FOR-604?page=comments#action_12317898 ]
Gavin commented on FOR-604:
---
Ok, I have made the changes needed. You can view it in action, I have uploaded
a basic site and at http://apache.minitutorials.com/samples/sample.html you can
see the new CSS changes in action.
I am not all that familiar with svn, although it did state that basic.css could
not be diff'd (or something like that)
If somebody wants to explain how I can commit these changes, if I can not then
please paste the following into /pelt/css/basic.css as a replacement for the
code in my earlier message above.
.note, .warning, .fixme {
border: solid black 1px;
margin: 1em 3em;
}
.note .label {
background: #369;
color: white;
font-weight: bold;
padding: 5px 10px;
}
.note .content {
background: #F0F0FF;
color: black;
line-height: 120%;
font-size: 90%;
padding: 5px 10px;
}
.warning .label {
background: #C00;
color: white;
font-weight: bold;
padding: 5px 10px;
}
.warning .content {
background: #FFF0F0;
color: black;
line-height: 120%;
font-size: 90%;
padding: 5px 10px;
}
.fixme .label {
background: #C6C600;
font-weight: bold;
padding: 5px 10px;
}
.fixme .content {
padding: 5px 10px;
}
---
I guess to be consistent then leather-dev/css/basic.css will also need to
be changed the same way. I will load leather-dev and make the changes,
making sure that it does not break anything else and then post back here.
Is there anything else I need to do here, doc changes ?
Gav...
The document-v* warning element does not get rendered properly
--
Key: FOR-604
URL: http://issues.apache.org/jira/browse/FOR-604
Project: Forrest
Type: Bug
Versions: 0.8-dev
Reporter: David Crossley
Fix For: 0.8-dev
Attachments: 604-screenshot.png
The warning element is rendered differently to the note element. Perhaps
it only happens with the pelt skin - not yet verified. See screenshot.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (FOR-604) The document-v* warning element does not get rendered properly
Thanks Gavin, i will reply here to try to keep commentary
inside the Issue tracker to a minimum.
...
Gavin (JIRA) wrote:
[
http://issues.apache.org/jira/browse/FOR-604?page=comments#action_12317898 ]
Gavin commented on FOR-604:
---
Ok, I have made the changes needed. You can view it in action, I have
uploaded a basic site and at
http://apache.minitutorials.com/samples/sample.html you can see the new CSS
changes in action.
Thanks that is great.
I am not all that familiar with svn, although it did state that basic.css
could not be diff'd (or something like that)
Do you have an SVN checkout, or are you using a packaged release?
This doc explains both situations.
http://forrest.apache.org/contrib.html#patch
If somebody wants to explain how I can commit these changes,
You cannot. Only committers can directly change the source control system.
http://forrest.apache.org/who.html
All other developers need to send patches.
if I can not then please paste the following into /pelt/css/basic.css as a
replacement for the code in my earlier message above.
It would be far better to provide a diff if you can.
Doing copy-and-paste is too error prone.
If you cannot manage it, then i will use this text.
.note, .warning, .fixme {
border: solid black 1px;
margin: 1em 3em;
}
.note .label {
background: #369;
color: white;
font-weight: bold;
padding: 5px 10px;
}
.note .content {
background: #F0F0FF;
color: black;
line-height: 120%;
font-size: 90%;
padding: 5px 10px;
}
.warning .label {
background: #C00;
color: white;
font-weight: bold;
padding: 5px 10px;
}
.warning .content {
background: #FFF0F0;
color: black;
line-height: 120%;
font-size: 90%;
padding: 5px 10px;
}
.fixme .label {
background: #C6C600;
font-weight: bold;
padding: 5px 10px;
}
.fixme .content {
padding: 5px 10px;
}
---
I guess to be consistent then leather-dev/css/basic.css will also need to
be changed the same way. I will load leather-dev and make the changes,
making sure that it does not break anything else and then post back here.
Thanks.
Is there anything else I need to do here, doc changes ?
No that should be it.
David
[jira] Commented: (FOR-605) CSS enhancements needed for MOTD area inside Table of Contents
[ http://issues.apache.org/jira/browse/FOR-605?page=comments#action_12317899 ] Gavin commented on FOR-605: --- I removed the comment tags from the motd in /forrest/site-author/skinconf.xml but it has made no difference. Can you tell me how to enable motd so I can check it out. Looking at http://forrest.apache.org/pluginDocs/plugins_0_80/index.html where it displays correctly it is a width problem somewhere. Due to long URL description links on pages that have motd also, this would probably be unresolvable with motd in its current position, CSS or not. Moving motd above or below might be a better idea, but I'll have a play and let you see what I come up with. Gav... CSS enhancements needed for MOTD area inside Table of Contents -- Key: FOR-605 URL: http://issues.apache.org/jira/browse/FOR-605 Project: Forrest Type: Bug Versions: 0.8-dev Reporter: David Crossley Fix For: 0.8-dev Attachments: 605-screenshot.png The Message of the Day (MOTD) facility inserts a panel at the top right of the Table of Contents (ToC). However this panel interferes with the flow of text in the ToC, forcing items to be line-wrapped to a narrow width. The MOTD is not properly implemented with CSS, probably needs its own definition. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (FOR-601) Last modified time of Goggle Sitemap incorrect
Rasik Pandey wrote: In my opinion we should not be adding a last-modified time until we can add a proper one. This element is optional in the google sitemap and I am sure that Google would appreciate no information over and above false information. I only use it because I don't use Forrest in a dynamic environment, but all my pages are created dynamically at build time. But the build time is not the last modified time, it is only the last generated time. Even if 100% of *your* pages are changed in between builds this is very unusual and should not be the normal behaviour for the plugin. Do you think a map:generator could be responsible for adding this or making the info available to the the http header if it has access to the necessary objects. There are a number of options: - create a special generator that adds the last-modified time to meta-data based on src file timestamp (as you appear to be suggesting) - how would this then make it into the google sitemap? IMHO, this is the best option. The LinkStatusGenerator can then read it from the http header and added it to its xml output. This would only work if we generate the page, thus to create a sitemap in dynamic mode we would have to generate every single page. It seems clear to me that we should not add a last modified time when running in dynamic mode. As for it being the best option, lets wait and see what Ferdinand has to say before deciding that. Ross
Re: [jira] Commented: (FOR-604) The document-v* warning element does not get rendered properly
basic.css.diff uploaded to issues,
thanks
Gav...
- Original Message -
From: David Crossley [EMAIL PROTECTED]
To: dev@forrest.apache.org
Sent: Sunday, August 07, 2005 5:58 PM
Subject: Re: [jira] Commented: (FOR-604) The document-v* warning element
does not get rendered properly
| Thanks Gavin, i will reply here to try to keep commentary
| inside the Issue tracker to a minimum.
| ...
|
| Gavin (JIRA) wrote:
| [
http://issues.apache.org/jira/browse/FOR-604?page=comments#action_12317898 ]
|
| Gavin commented on FOR-604:
| ---
|
| Ok, I have made the changes needed. You can view it in action, I have
uploaded a basic site and at
http://apache.minitutorials.com/samples/sample.html you can see the new CSS
changes in action.
|
| Thanks that is great.
|
| I am not all that familiar with svn, although it did state that
basic.css could not be diff'd (or something like that)
|
| Do you have an SVN checkout, or are you using a packaged release?
| This doc explains both situations.
| http://forrest.apache.org/contrib.html#patch
|
| If somebody wants to explain how I can commit these changes,
|
| You cannot. Only committers can directly change the source control system.
| http://forrest.apache.org/who.html
| All other developers need to send patches.
|
| if I can not then please paste the following into /pelt/css/basic.css as
a replacement for the code in my earlier message above.
|
| It would be far better to provide a diff if you can.
| Doing copy-and-paste is too error prone.
| If you cannot manage it, then i will use this text.
|
| .note, .warning, .fixme {
|border: solid black 1px;
|margin: 1em 3em;
| }
|
| .note .label {
|background: #369;
|color: white;
|font-weight: bold;
| padding: 5px 10px;
| }
| .note .content {
|background: #F0F0FF;
|color: black;
|line-height: 120%;
|font-size: 90%;
| padding: 5px 10px;
| }
| .warning .label {
|background: #C00;
|color: white;
|font-weight: bold;
| padding: 5px 10px;
| }
| .warning .content {
|background: #FFF0F0;
|color: black;
|line-height: 120%;
|font-size: 90%;
| padding: 5px 10px;
| }
| .fixme .label {
|background: #C6C600;
|font-weight: bold;
| padding: 5px 10px;
| }
| .fixme .content {
|padding: 5px 10px;
| }
|
|
---
| I guess to be consistent then leather-dev/css/basic.css will also need
to
| be changed the same way. I will load leather-dev and make the changes,
| making sure that it does not break anything else and then post back
here.
|
| Thanks.
|
| Is there anything else I need to do here, doc changes ?
|
| No that should be it.
|
| David
|
|
| --
| No virus found in this incoming message.
| Checked by AVG Anti-Virus.
| Version: 7.0.338 / Virus Database: 267.10.1/64 - Release Date: 4/08/2005
|
|
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.1/64 - Release Date: 4/08/2005
[jira] Updated: (FOR-604) The document-v* warning element does not get rendered properly
[ http://issues.apache.org/jira/browse/FOR-604?page=all ] Gavin updated FOR-604: -- Attachment: basic.css.diff The document-v* warning element does not get rendered properly -- Key: FOR-604 URL: http://issues.apache.org/jira/browse/FOR-604 Project: Forrest Type: Bug Versions: 0.8-dev Reporter: David Crossley Fix For: 0.8-dev Attachments: 604-screenshot.png, basic.css.diff The warning element is rendered differently to the note element. Perhaps it only happens with the pelt skin - not yet verified. See screenshot. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FOR-604) The document-v* warning element does not get rendered properly
[ http://issues.apache.org/jira/browse/FOR-604?page=comments#action_12317907 ] Gavin commented on FOR-604: --- I have attatched basic.css.diff for inclusion. Thanks Gav... The document-v* warning element does not get rendered properly -- Key: FOR-604 URL: http://issues.apache.org/jira/browse/FOR-604 Project: Forrest Type: Bug Versions: 0.8-dev Reporter: David Crossley Fix For: 0.8-dev Attachments: 604-screenshot.png, basic.css.diff The warning element is rendered differently to the note element. Perhaps it only happens with the pelt skin - not yet verified. See screenshot. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Simple committership
Thanks so much for taking the time to reply to this important topic. A big effort, i can see. I am going to reply to this in bits and pieces i.e. not all at once tonight. Please would other members of our community (everyone, not just PMC members) also add their view. More below ... Thorsten Scherler wrote: Nicola Ken Barozzi wrote: snip valuable background information/ If we want to include simple committership as a role, I would like to hear someone explain how simple committership will solve more issues than it may cause, especially given the above. In particular, I would like to have some real-life examples that show how simple committership would have been useful. Like David and Nicola stated the Forrest project normally votes all committer directly into the PMC as well. I personally see special occasions (besides GSoC) where I would like to see a simple committership or like I would call it PMC incubation. Here you say special occasions. We do already have the capability to add people as committers which are not being PMC members also. However you are actually talking below about this being the normal course. It should follow the basic idea of the Apache Incubator [1] which is for new projects at Apache. A large part of the Incubator's effort will be devoted to providing documentation on how the Foundation works, and how to get things done within its framework. As a consequence, it is expected that the Incubator will also become a reference for new contributors to any of the Apache projects. Unfortunately not much of that documentation has arisen. People seem to rush onwards and forget. People coming afterward need to learn all over again. My reasoning is that we can ensure that this newbies can learn the apache way to it fullest (which is one of the most important point in the process to become a PMC member) without the pressure to be an official PMC member. But it is a never-ending process. We are all continually learning. And most important, that way is evolving. So for newbies (all of us actually), the only way is to start walking. There should not be a fence across the path which causes us to wait until deemed capable. It is the mention of pressure that i wonder might be the key to your concerns. Apache projects should be fun, no pressure. I hope that you are aware that as a PMC member, or as a developer, you do as much work as you feel like doing. You do not need to participate in every discussion, just because it concerns the PMC. Neither do you need to participate in every vote or in every development issue. The more committers we have, the more pairs of eyes are watching the svn diff emails. But every committer cannot be expected to notice every problem. Unlax, doc. Let the averages work for us. As long as each of us do make some little effort, then the whole will work. New committers have to learn a) how the Foundation works b) how the Project works One can argue that this should be learned before becoming a committer on the mls but I see a certain process behind it which takes time (some times too much). Therefore there should not be a learn first situation. Now it was asked for a real-life example. That could be myself. ;-) I have been a Wyona CMS committer before it became an official Apache Incubator project. The company Wyona donated then the code base to the ASF as cocoon subproject in incubation called Apache Lenya. I had general experience in how a open source project and community is working but that have been quite different from the ASF way that I had to learn. Within the one year where Apache Lenya has been in the incubator I learned the basics (IMO learning) on how the Foundation works (a) (never stops). As Apache Lenya committer we were given not only committing rights to lenya but as well to cocoon, forrest and xml. That was not the usual way. Normally one only becomes a committer for the specific project that you are directly involved with. This thing about Cocoon committers being given commit access to Forrest, happened a long time ago, before Forrest was a project of its own. We have already said that the situation needs review, now that we are a top-level project. It was an experiment to attempt to boost the Forrest base. At one stage the project was floundering with not enough developers. Interesting that it did not attract many people from the Cocoon community. I am sure glad that you are here, but i reckon that you would be here even if we did not have that arrangement. You would have contributed patches, and we would have noticed your commitment and made you a PMC member. Also it would have been only for xml-commons, not for every project at xml.apache.org e.g. Xerces. I started to use them here on forrest when getting into the documentation for lenya. In lenya we are using forrest to create our documentation and website. We had a custom skin and heaps problems with maintaining it
Re: Simple committership
David Crossley wrote: Thanks so much for taking the time to reply to this important topic. A big effort, i can see. I am going to reply to this in bits and pieces i.e. not all at once tonight. Please would other members of our community (everyone, not just PMC members) also add their view. OK, well, I don't speak much but I do think this is an important topic and my work pulling the committer doc together has got my mind wrapped around this these days anyway, so here goes. More below ... Thorsten Scherler wrote: Nicola Ken Barozzi wrote: snip valuable background information/ ...snip lots of good discussion... My reasoning is that we can ensure that this newbies can learn the apache way to it fullest (which is one of the most important point in the process to become a PMC member) without the pressure to be an official PMC member. But it is a never-ending process. We are all continually learning. And most important, that way is evolving. So for newbies (all of us actually), the only way is to start walking. There should not be a fence across the path which causes us to wait until deemed capable. It is the mention of pressure that i wonder might be the key to your concerns. Apache projects should be fun, no pressure. I hope that you are aware that as a PMC member, or as a developer, you do as much work as you feel like doing. You do not need to participate in every discussion, just because it concerns the PMC. Neither do you need to participate in every vote or in every development issue. Maybe this concept should be added to the new committer doc so it is stated clearly what the expectations of a comitter are. I am not terribly involved in Forrest at this time, but even I feel guilty when I don't have time to read the mail lists or tinker in Forrest for a while. Now, that is part of my personality but I suspect that many people who commit themselves to projects like this naturally have a similar feeling of responsibilty (and internal pressure). The more committers we have, the more pairs of eyes are watching the svn diff emails. But every committer cannot be expected to notice every problem. Unlax, doc. Let the averages work for us. As long as each of us do make some little effort, then the whole will work. New committers have to learn a) how the Foundation works b) how the Project works One can argue that this should be learned before becoming a committer on the mls but I see a certain process behind it which takes time (some times too much). Therefore there should not be a learn first situation. While I agree with Thorsten that these are important things to know, I don't believe it is a focus limited to committers. I believe it should be something that devs pick up as well and I think that spending a decent amount of time on the dev list and really reading what is going on serves this purpose maybe more than you think. See below for more. ... snip more stuff ... I started to use them here on forrest when getting into the documentation for lenya. In lenya we are using forrest to create our documentation and website. We had a custom skin and heaps problems with maintaining it because forrest is developing very rapid. The lenya skin was nearly all div based. At the time I started here in forrest there was an issue about an all div based skin. The result is called pelt. While I was developing the skin I had simple committership to forrest. I am happy that I could concentrate on developing the skin and meanwhile learning all the new responsibilities of a PMC member. After a while I was invited to join the PMC and helping on the long run of forrest. I could fully participate in the project as committer. I just did not had a counting vote but normally forrest consider every concern. Thankfully we all agreed with your work. It could be disastrous if we didn't agree and you had no binding vote in the matter. Agreed about the vote. I think if you are trusted to commit you should be trusted to vote. It only makes sense. I'll take this space to pipe up with my little shout on the whole concept as well. I see the value in where Thorsten is coming from but it is interesting that the focus is on allowing commits but not allowing PMC activity. If the PMC is going to invite someone in as a committer, it seems to me that they have looked at that person's work and attitude for a certain amount of time and decided that they trust that person enough to let them tinker directly with the code. That is a huge responsibility from my perspective and to allow that but not really allow them into the project itself strikes me as a little weird. Sort of giving them a direct hand in the DoC part of CoPDoC, but not letting them fully into the CoP part. If the concern for an incubation place is not code, but project management, then why not consider the opposite of the incubator being proposed and create a PMC
Re: Simple committership
Addi wrote: David Crossley wrote: ... Thorsten Scherler wrote: Nicola Ken Barozzi wrote: snip valuable background information/ ...snip lots of good discussion... My reasoning is that we can ensure that this newbies can learn the apache way to it fullest (which is one of the most important point in the process to become a PMC member) without the pressure to be an official PMC member. There are *no* additional requirements to being a PMC member than there are to being a committer, therefore no additional pressure. The only reason for a PMC is that some things need to be discussed in private. These things are few and far between, votes for new committers, reports to the Board, security issues etc. (PMC members have a binding vote, I'll come to that later) It is the mention of pressure that i wonder might be the key to your concerns. Apache projects should be fun, no pressure. I hope that you are aware that as a PMC member, or as a developer, you do as much work as you feel like doing. You do not need to participate in every discussion, just because it concerns the PMC. Neither do you need to participate in every vote or in every development issue. Maybe this concept should be added to the new committer doc so it is stated clearly what the expectations of a comitter are. I am not terribly involved in Forrest at this time, but even I feel guilty when I don't have time to read the mail lists or tinker in Forrest for a while. Now, that is part of my personality but I suspect that many people who commit themselves to projects like this naturally have a similar feeling of responsibilty (and internal pressure). +1 Davids words are very important. There are *no* expectations on any member of an Apache project. We like people to be involved and we reward contributions (meritocracy), but we do not punish a lack of contributions. People come and go as their needs change and we adapt to those changes. New committers have to learn a) how the Foundation works b) how the Project works One can argue that this should be learned before becoming a committer on the mls but I see a certain process behind it which takes time (some times too much). Therefore there should not be a learn first situation. I would say there *can't* be a learn first approach. When have you learnt everything? While I agree with Thorsten that these are important things to know, I don't believe it is a focus limited to committers. I believe it should be something that devs pick up as well and I think that spending a decent amount of time on the dev list and really reading what is going on serves this purpose maybe more than you think. See below for more. +1 ... I started to use them here on forrest when getting into the documentation for lenya. In lenya we are using forrest to create our documentation and website. We had a custom skin and heaps problems with maintaining it because forrest is developing very rapid. The lenya skin was nearly all div based. At the time I started here in forrest there was an issue about an all div based skin. The result is called pelt. While I was developing the skin I had simple committership to forrest. I am happy that I could concentrate on developing the skin and meanwhile learning all the new responsibilities of a PMC member. After a while I was invited to join the PMC and helping on the long run of forrest. I could fully participate in the project as committer. I just did not had a counting vote but normally forrest consider every concern. Thankfully we all agreed with your work. It could be disastrous if we didn't agree and you had no binding vote in the matter. Agreed about the vote. I think if you are trusted to commit you should be trusted to vote. It only makes sense. I'll take this space to pipe up with my little shout on the whole concept as well. Here is the only real difference between a committer and a PMC member, PMC members have a *binding* vote. This does not mean other members of the community do not have a vote, in fact they do. It is used to gauge the general feeling of the community an, on the rare occasions a vote is called for it can be a powerful feedback mechanism for the PMC. Imagine a vote for a release. Only PMC members can actually prevent a release with a binding -1 vote. However, if a user casts a (non-binding) -1 along with a bug report it is the job of the PMC to examine this and, if necessary make the vote a binding one by supporting it. So why have binding and non-binding votes then? Very occasional someone comes to an Open Source project with the intention of causing trouble. We deal with these people by having mechanisms to cut them out. That is, their vote is non-binding. As soon as someone shows they are reasonable, cooperative people we will listen to their view, binding or otherwise. In other words, I totally agree with Addi, if you are trusted to commit you should be
[jira] Created: (FOR-606) forrest seedBusiness refers to ...plugin.input.Resume
forrest seedBusiness refers to ...plugin.input.Resume - Key: FOR-606 URL: http://issues.apache.org/jira/browse/FOR-606 Project: Forrest Type: Bug Versions: 0.8-dev Environment: Any Reporter: kevin Priority: Minor forrest seedBusiness refers to ...plugin.input.Resume when building site. Not in whiteboard either. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (FOR-607) site-author - Versioned Docs and Plugins tabs not highlighted
site-author - Versioned Docs and Plugins tabs not highlighted - Key: FOR-607 URL: http://issues.apache.org/jira/browse/FOR-607 Project: Forrest Type: Bug Components: Documentation and website Versions: 0.8-dev Environment: Any Reporter: kevin Priority: Minor site-author Versioned Docs and Plugins tabs not highlighted when viewing docs -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (FOR-606) forrest seedBusiness refers to ...plugin.input.Resume
[ http://issues.apache.org/jira/browse/FOR-606?page=all ] Ross Gardler reassigned FOR-606: Assign To: Ross Gardler forrest seedBusiness refers to ...plugin.input.Resume - Key: FOR-606 URL: http://issues.apache.org/jira/browse/FOR-606 Project: Forrest Type: Bug Versions: 0.8-dev Environment: Any Reporter: kevin Assignee: Ross Gardler Priority: Minor forrest seedBusiness refers to ...plugin.input.Resume when building site. Not in whiteboard either. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FOR-606) forrest seedBusiness refers to ...plugin.input.Resume
[ http://issues.apache.org/jira/browse/FOR-606?page=all ] Ross Gardler closed FOR-606: Fix Version: 0.8-dev Resolution: Fixed Added basic plugin to whiteboard - thanks for letting us know of this oversight. forrest seedBusiness refers to ...plugin.input.Resume - Key: FOR-606 URL: http://issues.apache.org/jira/browse/FOR-606 Project: Forrest Type: Bug Versions: 0.8-dev Environment: Any Reporter: kevin Assignee: Ross Gardler Priority: Minor Fix For: 0.8-dev forrest seedBusiness refers to ...plugin.input.Resume when building site. Not in whiteboard either. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Simple committership
Ross Gardler wrote: Addi wrote: David Crossley wrote: Thorsten Scherler wrote: snip valuable background information/ ...snip lots of good discussion... My reasoning is that we can ensure that this newbies can learn the apache way to it fullest (which is one of the most important point in the process to become a PMC member) without the pressure to be an official PMC member. There are *no* additional requirements to being a PMC member than there are to being a committer, therefore no additional pressure. ... (I need to clarify Ross' statements, so i split this paragraph apart. Also it is good to build upon this, to ensure that everyone who cares can know our background.) The PMC as a whole does have additional responsibilities: http://forrest.apache.org/guidelines.html#roles The only reason for a PMC is that some things need to be discussed in private. That is creating confusion between the PMC and the private pmc mailing list. Ross is talking about the reasons for the private mailing list. The PMC does as much business as possible on the dev mailing list. The main reason for a PMC is the Apache Software Foundation, being a corporation, needs to meet statutory requirements and also have a mechanism for oversight of communities and software distributions. The board establishes various committees to have such management oversight, with each PMC chair having primary responsibility. I don't dare to explain further. We carefully evolved this document to say it as well as possible: http://www.apache.org/foundation/how-it-works.html#structure Back to the reasons for a private discussion list: These things are few and far between, votes for new committers, reports to the Board, security issues etc. Mainly for a place to discuss private things when necessary, e.g. personal and security issues. At Apache Forrest we decided to also conduct votes for new PMC members/committers in private so that we can speak frankly and any one of us can say, No we need to wait a while for this person, for these reasons. We feel that such stuff is not good to do in public. Other ASF projects do it differently. You mention Board report as being a private issue. Not really. The quarterly board report is entirely my responsibility as the PMC chair. I don't need to discuss it with anyone beforehand. However i do seek the input of the Forrest PMC, as that is the way that i do things. Until now i have been doing that on the private PMC mailing list. I reckon that will change. Of course the board minutes become public anyway: http://www.apache.org/foundation/board/calendar.html (Forrest reports start May 2004, then Aug, Nov, Feb.) (PMC members have a binding vote, I'll come to that later) It is the mention of pressure that i wonder might be the key to your concerns. Apache projects should be fun, no pressure. I hope that you are aware that as a PMC member, or as a developer, you do as much work as you feel like doing. You do not need to participate in every discussion, just because it concerns the PMC. Neither do you need to participate in every vote or in every development issue. Maybe this concept should be added to the new committer doc so it is stated clearly what the expectations of a comitter are. I am not terribly involved in Forrest at this time, but even I feel guilty when I don't have time to read the mail lists or tinker in Forrest for a while. Now, that is part of my personality but I suspect that many people who commit themselves to projects like this naturally have a similar feeling of responsibilty (and internal pressure). +1 You are so insightful. That is spot on. Committed people create their own internal pressure by virtue of their dedication. Being able to manage one's personal pressure is life's art. This is the perfect point to ask everyone to read these two important messages about what it means to be committed and then managing one's energy and dealing with volunteeritis. http://www.apache.org/dev/committers.html#volunteer As usual, Roy's messages cut straight to the point and there is no need for any reply. Davids words are very important. There are *no* expectations on any member of an Apache project. We like people to be involved and we reward contributions (meritocracy), but we do not punish a lack of contributions. People come and go as their needs change and we adapt to those changes. New committers have to learn a) how the Foundation works b) how the Project works One can argue that this should be learned before becoming a committer on the mls but I see a certain process behind it which takes time (some times too much). Therefore there should not be a learn first situation. I would say there *can't* be a learn first approach. When have you learnt everything? While I agree with Thorsten that these are important things to know, I don't believe it is a focus limited to committers. I believe it should be
