If one of the primary aims are to gain more committers, then making it comfortable for those that are already committed should be an ancilary worry. Keeping the source tree as neutral as possible (regarding certain preferences like the IDE or it's project settings) presents the least resistance to the majority of perspective committers you'll encounter. You can probably prove this mathematically via theorem. By reducing the average energy the majority will need to expend to grok this stuff and finally get to a point to contribute, the more new committers you will gain overall. The more preferential content you inject into your code, into your system of organization, the more energy it takes someone to get to understand it. Give em a break, and make it dirt simple without any bias. Alan is probably affraid some setting in the IntelliJ files will cause an issue on his machine, his OS, or his particular configuration. Shit breaks all the time man :-). It breaks more for newbies. This stuff get's complex real quick when something goes wrong and when people are trying to do things fast a small bump can derail them.
BTW I don't see disregarding advice as disrespect at all. Please don't ever feel that you have to follow my advice. The respect is not the primary objective of this process; it's just a great by product that flows both ways. I'm here because I'm interested in what you guys are doing and wanted to be a part of it in some capacity. Hopefully, I can find more time rubbing elbows while tackling significant problems with y'all. Right now I thought the best I can do is grease your path to success by avoiding pitfalls, but even that I do poorly. Alex On Mon, Jan 5, 2009 at 1:31 PM, Jeremy Haile <[email protected]> wrote: > I definitely respect the mentors' opinions and want to learn from their > experience in the open-source community. None of my questions or challenges > to their ideas should be taken as disrespect. > > The current IDE project files are in active use by multiple core committers > to this project, who find them very useful. I've heard no reports of them > causing any real trouble for anyone else, and even if they were - it's not > hard to setup a separate IDEA project if you want to have one customized to > your liking. I don't understand why it's surprising that an email stating > only "Can we remove these?" with no further explanation would not be > questioned or challenged in some way. This doesn't indicate a lack of > respect for Alan - I certainly respect him and value the time and experience > he is devoting to this project! That doesn't mean I will always agree, > right or wrong... > > I do agree that this is a small issue, much like the build system issue. > In my humble opinion, neither of these are causing any real issues to the > project at the moment. I do think JSecurity has lots of big issues - how to > attract more users (for example, better integration with other projects, > etc), how to improve our website, how to improve our documentation, what are > the next "killer features" that need to be added to spur more support and > adoption, etc. I would love to be brainstorming with you guys and getting > your ideas and advice on these issues. > > The IDE project files are providing a real benefit to the current > committers of this project, and causing very little (if any) harm. If this > changes in the future, it's a really simple task to remove them from SVN. > For now, I wish we could focus our time and effort on discussing the bigger > challenges facing JSecurity. > > Jeremy > > > > On Jan 5, 2009, at 12:30 PM, Alex Karasulu wrote: > > This is not a big issue but if you don't see the kinds of collisions IDE >> specific files in SVN cause in collaborative environments, then experience >> will eventually show you over time. I won't enumerate over how many people >> told me the same or how many painful experiences taught us this lesson. >> All >> in all, it's no big deal and these things will sort themselves out. If >> you >> feel you need to keep the files then go ahead. >> >> More importantly though, these kinds of threads are distracting. This is >> a >> simple suggestion by those who have learned these conventions after years >> of >> working in this community. You don't have to apply a mentor's advice if >> you >> don't want to and eventually incubation rules will be applied to sort out >> what really matters to the ASF. Although I have not been able to give you >> guys the kind of time I've wanted to, I was hoping to be here to help >> during >> these growing pains. I guess this last thread was a signal for me to kick >> in. To do this right, you guys need to trust and be open to the >> suggestions >> made. Mentors are not gods nor are they tyrants. They've just had more >> experience in this community and can provide some guidance. That does not >> make them better or more savvy. There's no golden mentor badge of honor >> :-). This project needs to incubate no matter what so why not get the >> most >> out of it. If everything we have to deal with together is met with >> difficulty then ask yourself why you're here! >> >> Let's together refuse to tolerate discord and gain as much as we can. All >> I >> can recommend at this point is for those new to the ASF to be a bit more >> open and trusting. To the mentors I recommend we have a little more >> patience and let these guys educate themselves from their own experiences. >> It's important for us to make suggestions and equally if not more >> important >> we must understand and accept that some advice will be disregarded. When >> advice is solicited we can give it gratis. On the flip side, if >> everything >> is a struggle and all advice is dismissed then what's there to mentor. In >> the end you just have to ask yourself why you bother to be here! (Note: >> same >> advice as above paragraph) >> >> I've had great personal and group experiences here at the ASF where I have >> mentored and been mentored. These have usually been ones where there has >> been mutual respect and the bonds formed have lasted for a lifetime. I >> remember one of my mentors, Noel, who is now the IPMC chair. He would >> give >> advice and stand back for us to make our own choices. Eventually we always >> wound up following his wise advice and gained a lot of respect for him >> through his patience. However we also did pay for having to learn lessons >> on >> our own with more time in the incubator :-(. It's all about tradeoffs >> without absolutes. >> >> I apologize in advance if this email touches nerves. Just being sincere >> without any objective but to reduce the unnecessary discord. >> >> Regards, >> Alex >> > >
