Re: need help about code mobility
Brian Pontarelli <[email protected]>
| Newsgroups | gmane.comp.java.sun.jini |
|---|---|
| Message-ID | <[email protected]> |
>> Agreed. And I think as the mail lists move over a set of guidelines will >> probably be setup as part of the Apache process. This will help in >> guiding newer users, but there will still be a lot of users who don't >> read them, so be prepared. >> >> > > If a lot of users won't read them, why would we waste the effort writing > them? > Sorry, I mis-phrased that. "Some users won't read them". This is just standard on most email lists for projects that have a large user base and are gaining popularity (which I'm really hoping for Jini). Still worth writing them if 70-80% read them. And as you inform more folks, you hope that number goes up. > IMHO, we are all grown up enough to know about social contracts and how > to behave on mailing lists same as we all know enough to behave > appropriately in public/at work. Those social contracts change over > time and are defined by the community as a whole. And if someone > breaches the contract, the community as a whole should speak up. > I agree, but it just happens. Not a lot and clear guidelines and a very well laid out project homepage (apache format is pretty decent) helps reduce the spamming a lot. However, if someone breaches the contract I think a friendly reminder should be given but not a public flogging. If they continue to spam, they can be banned. In most cases something like: "Thanks for the question and for future postings be sure to read over the jini mailing lists code of conduct here http://jini.org/foo/bar as it really helps speed up the answer process." Should be sufficient to let the person know that they didn't exactly follow the protocol. > And, as an experienced helper there's probably a few things I'd mention: > > (1) It costs me time and effort to provide help - I look for signs that > the helpee is putting in similar effort (e.g. I don't want to see > endless questions which could be answered better by existing > documentation that the helpee should go wade through just as I have). > Yep. You have to look for this otherwise you might as well bail since the help isn't working. > (2) Some people can't be helped - you ask for information and they don't > provide it for one of many reasons. I've personally lost count of the > number of times I've seen someone complain they get an exception without > naming it and posting the stack trace. I also marvel at the number of > people that can't simply copy the contents of the console output and > mail it. That said, we do have one consistent troublespot to work on > and that is network config - we need a better way to collect up and > communicate that information - network diagrams with IP addresses, > location/position of firewalls etc. This isn't easily solved by a tool > as that can only capture config local to a machine and that often is not > the issue. > Well, let's teach them how (windows: select console output -> hit enter key to copy to clipboard. Linux: select console output -> middle mouse click to paste it or ctrl-insert to copy to clipboard). As for the network stuff, that's a whole separate discussion that I guarantee we will have once things get settled over at Apache ;) hehe > (3) Some people can't be helped part II - they listen to your advice, > ignore it and proceed in their own direction - nothing wrong with that > but if you walk your own path, you can't expect others to walk it with > you, though they might. > Yeah, ego at work there. I just end up ignoring those folks most of the time. These are probably the worse because you can't teach them or help them. The code of conduct should probably have some method for removing members like these after they bother the list for a few posts or something like that. -bp -------------------------------------------------------------------------- Getting Started: http://www.jini.org/wiki/Category:Getting_Started Community Web Site: http://jini.org jini-users Archive: http://archives.java.sun.com/archives/jini-users.html Unsubscribing: email "signoff JINI-USERS" to [email protected]