[jira] [Closed] (QPID-4836) Add design guidelines to project etiquette html page
[ https://issues.apache.org/jira/browse/QPID-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed QPID-4836. - Add design guidelines to project etiquette html page Key: QPID-4836 URL: https://issues.apache.org/jira/browse/QPID-4836 Project: Qpid Issue Type: Task Components: Documentation Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Attachments: QPID-4836-design-guidelines.patch On a number of occasions, I've been involved in Qpid changes that have required rework because certain aspects of the design were not considered early on. To mitigate this, I'd like to add a Design Checklist to the Qpid web site that we can all refer to, either when designing features or reviewing other people's changes. I'd like to re-purpose http://qpid.apache.org/qpid_project_etiquette_guide.html to include this information, probably renaming it to something like Qpid Project Developers Guide. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4836) Add design guidelines to project etiquette html page
[ https://issues.apache.org/jira/browse/QPID-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved QPID-4836. --- Resolution: Fixed Assignee: Philip Harvey (was: Justin Ross) This has been in place for some time. Add design guidelines to project etiquette html page Key: QPID-4836 URL: https://issues.apache.org/jira/browse/QPID-4836 Project: Qpid Issue Type: Task Components: Documentation Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Attachments: QPID-4836-design-guidelines.patch On a number of occasions, I've been involved in Qpid changes that have required rework because certain aspects of the design were not considered early on. To mitigate this, I'd like to add a Design Checklist to the Qpid web site that we can all refer to, either when designing features or reviewing other people's changes. I'd like to re-purpose http://qpid.apache.org/qpid_project_etiquette_guide.html to include this information, probably renaming it to something like Qpid Project Developers Guide. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4836) Add design guidelines to project etiquette html page
[ https://issues.apache.org/jira/browse/QPID-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13656885#comment-13656885 ] Philip Harvey commented on QPID-4836: - Thanks Justin, I've edited that wiki page. I renamed it too (see below) - hope that doesn't cause too much disruption to your changes. https://cwiki.apache.org/confluence/display/qpid/Qpid+Project+Developers%27+Guide Add design guidelines to project etiquette html page Key: QPID-4836 URL: https://issues.apache.org/jira/browse/QPID-4836 Project: Qpid Issue Type: Task Components: Documentation Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Attachments: QPID-4836-design-guidelines.patch On a number of occasions, I've been involved in Qpid changes that have required rework because certain aspects of the design were not considered early on. To mitigate this, I'd like to add a Design Checklist to the Qpid web site that we can all refer to, either when designing features or reviewing other people's changes. I'd like to re-purpose http://qpid.apache.org/qpid_project_etiquette_guide.html to include this information, probably renaming it to something like Qpid Project Developers Guide. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-4836) Add design guidelines to project etiquette html page
[ https://issues.apache.org/jira/browse/QPID-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned QPID-4836: --- Assignee: Justin Ross (was: Philip Harvey) Add design guidelines to project etiquette html page Key: QPID-4836 URL: https://issues.apache.org/jira/browse/QPID-4836 Project: Qpid Issue Type: Task Components: Documentation Reporter: Philip Harvey Assignee: Justin Ross Priority: Minor Attachments: QPID-4836-design-guidelines.patch On a number of occasions, I've been involved in Qpid changes that have required rework because certain aspects of the design were not considered early on. To mitigate this, I'd like to add a Design Checklist to the Qpid web site that we can all refer to, either when designing features or reviewing other people's changes. I'd like to re-purpose http://qpid.apache.org/qpid_project_etiquette_guide.html to include this information, probably renaming it to something like Qpid Project Developers Guide. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4836) Add design guidelines to project etiquette html page
[ https://issues.apache.org/jira/browse/QPID-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4836: Status: Ready To Review (was: In Progress) Add design guidelines to project etiquette html page Key: QPID-4836 URL: https://issues.apache.org/jira/browse/QPID-4836 Project: Qpid Issue Type: Task Components: Documentation Reporter: Philip Harvey Assignee: Justin Ross Priority: Minor Attachments: QPID-4836-design-guidelines.patch On a number of occasions, I've been involved in Qpid changes that have required rework because certain aspects of the design were not considered early on. To mitigate this, I'd like to add a Design Checklist to the Qpid web site that we can all refer to, either when designing features or reviewing other people's changes. I'd like to re-purpose http://qpid.apache.org/qpid_project_etiquette_guide.html to include this information, probably renaming it to something like Qpid Project Developers Guide. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4836) Add design guidelines to project etiquette html page
[ https://issues.apache.org/jira/browse/QPID-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13656938#comment-13656938 ] Justin Ross commented on QPID-4836: --- No problem at all. I'll update the pointer. I like the new title better. Add design guidelines to project etiquette html page Key: QPID-4836 URL: https://issues.apache.org/jira/browse/QPID-4836 Project: Qpid Issue Type: Task Components: Documentation Reporter: Philip Harvey Assignee: Justin Ross Priority: Minor Attachments: QPID-4836-design-guidelines.patch On a number of occasions, I've been involved in Qpid changes that have required rework because certain aspects of the design were not considered early on. To mitigate this, I'd like to add a Design Checklist to the Qpid web site that we can all refer to, either when designing features or reviewing other people's changes. I'd like to re-purpose http://qpid.apache.org/qpid_project_etiquette_guide.html to include this information, probably renaming it to something like Qpid Project Developers Guide. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4836) Add design guidelines to project etiquette html page
Philip Harvey created QPID-4836: --- Summary: Add design guidelines to project etiquette html page Key: QPID-4836 URL: https://issues.apache.org/jira/browse/QPID-4836 Project: Qpid Issue Type: Task Components: Documentation Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor On a number of occasions, I've been involved in Qpid changes that have required rework because certain aspects of the design were not considered early on. To mitigate this, I'd like to add a Design Checklist to the Qpid web site that we can all refer to, either when designing features or reviewing other people's changes. I'd like to re-purpose http://qpid.apache.org/qpid_project_etiquette_guide.html to include this information, probably renaming it to something like Qpid Project Developers Guide. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4836) Add design guidelines to project etiquette html page
[ https://issues.apache.org/jira/browse/QPID-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4836: Attachment: QPID-4836-design-guidelines.patch attached patch for review Add design guidelines to project etiquette html page Key: QPID-4836 URL: https://issues.apache.org/jira/browse/QPID-4836 Project: Qpid Issue Type: Task Components: Documentation Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Attachments: QPID-4836-design-guidelines.patch On a number of occasions, I've been involved in Qpid changes that have required rework because certain aspects of the design were not considered early on. To mitigate this, I'd like to add a Design Checklist to the Qpid web site that we can all refer to, either when designing features or reviewing other people's changes. I'd like to re-purpose http://qpid.apache.org/qpid_project_etiquette_guide.html to include this information, probably renaming it to something like Qpid Project Developers Guide. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4836) Add design guidelines to project etiquette html page
[ https://issues.apache.org/jira/browse/QPID-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13656125#comment-13656125 ] Justin Ross commented on QPID-4836: --- Right now I have the new proposed website pointing at the wiki version of this: https://cwiki.apache.org/qpid/qpid-project-etiquette-guide.html I thought that was a more appropriate place to keep developer guidelines. I'm not really wed to one or another location, but we should try to focus our attention on just one, I figure. Add design guidelines to project etiquette html page Key: QPID-4836 URL: https://issues.apache.org/jira/browse/QPID-4836 Project: Qpid Issue Type: Task Components: Documentation Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Attachments: QPID-4836-design-guidelines.patch On a number of occasions, I've been involved in Qpid changes that have required rework because certain aspects of the design were not considered early on. To mitigate this, I'd like to add a Design Checklist to the Qpid web site that we can all refer to, either when designing features or reviewing other people's changes. I'd like to re-purpose http://qpid.apache.org/qpid_project_etiquette_guide.html to include this information, probably renaming it to something like Qpid Project Developers Guide. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Project Etiquette
Marnie McCormack wrote: Hi Rafi, Thanks for taking the time to write these. I think they're a good idea to have for new people. At risk of incurring your wrath - I found it them a little long, at first reading. I wonder if you'd consider a more concise version - be happy to have a shot at it if that'd be helpful and not cross making ? Please feel free, I'm not actively working on anything right now. I'll try to keep my wrath in check until I see what you produce. ;) I'd like to think we should welcome people in, tell them what they might need to know but I'm hoping we won't scare them off. What do you think ? I don't want to scare people too much. At the same time I don't want to have only a very dry list of process points that people can end up following to the letter with no real understanding of the spirit, and I think the most direct way to understand the spirit is to gain some real context in terms of the sorts of things that have and do actually happen. This may cause the length to grow a bit, but I don't think that's an issue. I would expect reading this material to be a tiny fraction of the overall time anyone who is serious is going to spend getting involved in qpid, and I think it is worthwhile time spent as it can give people a leg up. Those of us who have been around for a while have a long and complex shared history that shapes how we interact as a group, and while on the one hand it may be daunting to ask people to read the entire thing before they get involved, at the same time it puts them at a significant disadvantage not to give them any of it. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Project Etiquette
2009/12/10 Rafael Schloming rafa...@redhat.com Marnie McCormack wrote: Hi Rafi, Thanks for taking the time to write these. I think they're a good idea to have for new people. At risk of incurring your wrath - I found it them a little long, at first reading. I wonder if you'd consider a more concise version - be happy to have a shot at it if that'd be helpful and not cross making ? Please feel free, I'm not actively working on anything right now. I'll try to keep my wrath in check until I see what you produce. ;) I'd like to think we should welcome people in, tell them what they might need to know but I'm hoping we won't scare them off. What do you think ? I don't want to scare people too much. At the same time I don't want to have only a very dry list of process points that people can end up following to the letter with no real understanding of the spirit, and I think the most direct way to understand the spirit is to gain some real context in terms of the sorts of things that have and do actually happen. This may cause the length to grow a bit, but I don't think that's an issue. I would expect reading this material to be a tiny fraction of the overall time anyone who is serious is going to spend getting involved in qpid, and I think it is worthwhile time spent as it can give people a leg up. I agree that while brevity is always desirable, we don't necessarily want this to look like a list of rules. I think that this needs to be cast as an introduction to project etiquette rather than as prescriptive law. That said the existing format does look rather overwhelming. Maybe it can be broken up, or using folding sections on a web page... or simply use less words :-) People are much more likely to read if it looks easily digestible. -- Rob Those of us who have been around for a while have a long and complex shared history that shapes how we interact as a group, and while on the one hand it may be daunting to ask people to read the entire thing before they get involved, at the same time it puts them at a significant disadvantage not to give them any of it. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Project Etiquette
Hi Folks, Personally I think Carl's idea is a good one, as I am new :) I was involved with QPID and AMQP a few years ago and have only just come back to the fold. I think having a getting involved - etiquette section is a good idea. As has already been mentioned, there is a lot of latent awareness about how to go about things, but as a new member of the community it would certainly be of benefit to me to be able to read about it! cheers, Sam. Carl Trieloff wrote: Robert Godfrey wrote: 2009/12/8 Rafael Schloming rafa...@redhat.com A number of recent threads have made it clear that we have a fair amount of unspoken etiquette about how we do things around here, and the fact that it is unspoken can be confusing to newcomers and old-timers alike. Looking at a few other apache project web sites, they often seem to have a page or two devoted to documenting their project etiquette. I think this would be a good thing for us to have as well, and I've taken the liberty of trying to seed this effort with some content. I think there are some obvious places where it would make sense to formalize some of this etiquette into some lightweight process, e.g. having maintainers files in svn, having a sandbox for new code contributions, etc, however this text is *not* intended to be a proposal for that sort of thing, merely an attempt to put into words what I believe most of us consider to be the status quo wrt the unspoken etiquette of the project. Of course the problem with unspoken etiquette is that we might not all have the same concept of what it actually is, so please let me know if you disagree with something I've written or you think something important is missing. --Rafael All this sounds very sensible to me; and there's nothing I can immediately think of that I would like to add. Having this on a Getting Involved section of the website, along, perhaps, with a list of the Big Ideas people are currently working on would seem to make a lot of sense... -- Rob Should we also add a getting involved Etiquette section, i.e. if you are new, how should I work with the team... Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Project Etiquette
FWIW, the stuff I wrote was all intended for the benefit of new guys especially, even though I think it is equally good for us to have it written down for ourselves. I'm happy to add to it with some guidelines specifically for new contributors, I'm just less sure of what those are since it's been a while since I was a new contributor. If anyone has specific suggestions, please post and I'm happy to try to incorporate them somehow. As I mentioned, this wasn't intended to be a complete and definitive document, just a start that can evolve. --Rafael Sam Joyce wrote: Hi Folks, Personally I think Carl's idea is a good one, as I am new :) I was involved with QPID and AMQP a few years ago and have only just come back to the fold. I think having a getting involved - etiquette section is a good idea. As has already been mentioned, there is a lot of latent awareness about how to go about things, but as a new member of the community it would certainly be of benefit to me to be able to read about it! cheers, Sam. Carl Trieloff wrote: Robert Godfrey wrote: 2009/12/8 Rafael Schloming rafa...@redhat.com A number of recent threads have made it clear that we have a fair amount of unspoken etiquette about how we do things around here, and the fact that it is unspoken can be confusing to newcomers and old-timers alike. Looking at a few other apache project web sites, they often seem to have a page or two devoted to documenting their project etiquette. I think this would be a good thing for us to have as well, and I've taken the liberty of trying to seed this effort with some content. I think there are some obvious places where it would make sense to formalize some of this etiquette into some lightweight process, e.g. having maintainers files in svn, having a sandbox for new code contributions, etc, however this text is *not* intended to be a proposal for that sort of thing, merely an attempt to put into words what I believe most of us consider to be the status quo wrt the unspoken etiquette of the project. Of course the problem with unspoken etiquette is that we might not all have the same concept of what it actually is, so please let me know if you disagree with something I've written or you think something important is missing. --Rafael All this sounds very sensible to me; and there's nothing I can immediately think of that I would like to add. Having this on a Getting Involved section of the website, along, perhaps, with a list of the Big Ideas people are currently working on would seem to make a lot of sense... -- Rob Should we also add a getting involved Etiquette section, i.e. if you are new, how should I work with the team... Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Project Etiquette
Hi Rafi, Thanks for taking the time to write these. I think they're a good idea to have for new people. At risk of incurring your wrath - I found it them a little long, at first reading. I wonder if you'd consider a more concise version - be happy to have a shot at it if that'd be helpful and not cross making ? I'd like to think we should welcome people in, tell them what they might need to know but I'm hoping we won't scare them off. What do you think ? Regards, Marnie On Wed, Dec 9, 2009 at 11:55 AM, Rafael Schloming rafa...@redhat.comwrote: FWIW, the stuff I wrote was all intended for the benefit of new guys especially, even though I think it is equally good for us to have it written down for ourselves. I'm happy to add to it with some guidelines specifically for new contributors, I'm just less sure of what those are since it's been a while since I was a new contributor. If anyone has specific suggestions, please post and I'm happy to try to incorporate them somehow. As I mentioned, this wasn't intended to be a complete and definitive document, just a start that can evolve. --Rafael Sam Joyce wrote: Hi Folks, Personally I think Carl's idea is a good one, as I am new :) I was involved with QPID and AMQP a few years ago and have only just come back to the fold. I think having a getting involved - etiquette section is a good idea. As has already been mentioned, there is a lot of latent awareness about how to go about things, but as a new member of the community it would certainly be of benefit to me to be able to read about it! cheers, Sam. Carl Trieloff wrote: Robert Godfrey wrote: 2009/12/8 Rafael Schloming rafa...@redhat.com A number of recent threads have made it clear that we have a fair amount of unspoken etiquette about how we do things around here, and the fact that it is unspoken can be confusing to newcomers and old-timers alike. Looking at a few other apache project web sites, they often seem to have a page or two devoted to documenting their project etiquette. I think this would be a good thing for us to have as well, and I've taken the liberty of trying to seed this effort with some content. I think there are some obvious places where it would make sense to formalize some of this etiquette into some lightweight process, e.g. having maintainers files in svn, having a sandbox for new code contributions, etc, however this text is *not* intended to be a proposal for that sort of thing, merely an attempt to put into words what I believe most of us consider to be the status quo wrt the unspoken etiquette of the project. Of course the problem with unspoken etiquette is that we might not all have the same concept of what it actually is, so please let me know if you disagree with something I've written or you think something important is missing. --Rafael All this sounds very sensible to me; and there's nothing I can immediately think of that I would like to add. Having this on a Getting Involved section of the website, along, perhaps, with a list of the Big Ideas people are currently working on would seem to make a lot of sense... -- Rob Should we also add a getting involved Etiquette section, i.e. if you are new, how should I work with the team... Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Project Etiquette
A number of recent threads have made it clear that we have a fair amount of unspoken etiquette about how we do things around here, and the fact that it is unspoken can be confusing to newcomers and old-timers alike. Looking at a few other apache project web sites, they often seem to have a page or two devoted to documenting their project etiquette. I think this would be a good thing for us to have as well, and I've taken the liberty of trying to seed this effort with some content. I think there are some obvious places where it would make sense to formalize some of this etiquette into some lightweight process, e.g. having maintainers files in svn, having a sandbox for new code contributions, etc, however this text is *not* intended to be a proposal for that sort of thing, merely an attempt to put into words what I believe most of us consider to be the status quo wrt the unspoken etiquette of the project. Of course the problem with unspoken etiquette is that we might not all have the same concept of what it actually is, so please let me know if you disagree with something I've written or you think something important is missing. --Rafael Maintainers: The Qpid project consists of a number of major components spread across almost as many different languages. Thus it is rare for qpid committers to be experts in every single area of the project, and even those developers who are familiar with most of the components may not have time to be on the hook as a maintainer for more than a few. As such it is expected that qpid committers make some effort to reach out to their teammates before directly modifying components that are outside their chosen areas. Patch Submission: As a committer it can be difficult to decide whether/how to provide feedback when someone submits a patch. Often it is tempting to just fix up the patch and avoid the potentially socially awkward, and certainly slower process of telling someone that they got some part of it wrong. It is, however, very necessary to ensure that those who submit patches have every opportunity to learn what they need to know in order to eventually become a valued qpid committer. In that spirit, here are a few guidelines for dealing with patch submissions: - Make the submitter produce the final patch(s) as applied to the tree. The submitter must have the opportunity to know what it takes to produce a patch that needs little or no rework, because the ability to produce such patches will ultimately play an important role in becoming a qpid committer. This may involve making requests for trivial updates to the patch. If the submitter is serious about becoming a qpid committer, then such requests are necessary to ensure that they are familiar with subtle yet important aspects of the code, stylistic conventions, etc. Remember if a submitter becomes a committer, there will be no opportunity to fix up their work before it goes into SVN. - Make sure the submitter is familiar with project etiquette. It might be easy to mistake requests for trivial updates to a patch as rude or demeaning. This can be avoided if the submitter is familiar with the reasons for such requests. - Use your judgment. A one-time patch from someone who is clearly not interested in becoming a committer may need nothing more than a polite thank you regardless of the content. When in doubt, don't hesitate to ask people what their intentions are. - Break up unrelated changes. It wouldn't be considered correct for a committer to glom together too many unrelated changes within a single commit, and we shouldn't give that impression to patch submitters. Big Ideas: Every so often someone has a Big Idea that they get excited about and want to go do. Because this is a Big Idea, it has some impact on the overall project, and so they generally mail the list about it to give people the opportunity to comment, and then when nobody says anything they go off and do it. Fast forward six months later they commit/merge/enable/publish the result of their Big Idea, and suddenly everyone understands the full implications, and not everyone is happy. The resulting hubbub usually wastes a good chunk of everyone's time, potentially wastes all the time spent on the Big Idea, and engenders bad feelings all around. So, here are a few guidelines for making sure this doesn't happen, starting with how to write a good proposal for a Big Idea: - Make sure your proposal is recognizable as a proposal. Just because you hijacked some other thread and ranted about how things should be, doesn't mean it's clear you intend to go off and make them that way. An easy way to avoid ambiguity is to start a new thread for your proposal and stick proposal somewhere in the subject
Re: Project Etiquette
2009/12/8 Rafael Schloming rafa...@redhat.com A number of recent threads have made it clear that we have a fair amount of unspoken etiquette about how we do things around here, and the fact that it is unspoken can be confusing to newcomers and old-timers alike. Looking at a few other apache project web sites, they often seem to have a page or two devoted to documenting their project etiquette. I think this would be a good thing for us to have as well, and I've taken the liberty of trying to seed this effort with some content. I think there are some obvious places where it would make sense to formalize some of this etiquette into some lightweight process, e.g. having maintainers files in svn, having a sandbox for new code contributions, etc, however this text is *not* intended to be a proposal for that sort of thing, merely an attempt to put into words what I believe most of us consider to be the status quo wrt the unspoken etiquette of the project. Of course the problem with unspoken etiquette is that we might not all have the same concept of what it actually is, so please let me know if you disagree with something I've written or you think something important is missing. --Rafael All this sounds very sensible to me; and there's nothing I can immediately think of that I would like to add. Having this on a Getting Involved section of the website, along, perhaps, with a list of the Big Ideas people are currently working on would seem to make a lot of sense... -- Rob
Re: Project Etiquette
Robert Godfrey wrote: 2009/12/8 Rafael Schloming rafa...@redhat.com A number of recent threads have made it clear that we have a fair amount of unspoken etiquette about how we do things around here, and the fact that it is unspoken can be confusing to newcomers and old-timers alike. Looking at a few other apache project web sites, they often seem to have a page or two devoted to documenting their project etiquette. I think this would be a good thing for us to have as well, and I've taken the liberty of trying to seed this effort with some content. I think there are some obvious places where it would make sense to formalize some of this etiquette into some lightweight process, e.g. having maintainers files in svn, having a sandbox for new code contributions, etc, however this text is *not* intended to be a proposal for that sort of thing, merely an attempt to put into words what I believe most of us consider to be the status quo wrt the unspoken etiquette of the project. Of course the problem with unspoken etiquette is that we might not all have the same concept of what it actually is, so please let me know if you disagree with something I've written or you think something important is missing. --Rafael All this sounds very sensible to me; and there's nothing I can immediately think of that I would like to add. Having this on a Getting Involved section of the website, along, perhaps, with a list of the Big Ideas people are currently working on would seem to make a lot of sense... -- Rob Should we also add a getting involved Etiquette section, i.e. if you are new, how should I work with the team... Carl.
