Hello > View the length of the document this looks I don't feel this > is really a "hacking" guide. > But it is very good documentation , hacking bible?
Maybe it is a bit lengthy, but the whole idea is to have the reader up to speed in the community and let the reader know what is important to us. I don't think you can explain our community to a newcomer in 1 page and cover all the basic questions. A full story is much more valuable then a few short fragments directing to numerous documents explaining the same and more. The table of contents will show newcomers that this document is very important for them if they want to contribute. > It puts quite some weight into coding standards. Yes it does, but the reader should know that we want quality. We should explain how we are achieving that. The most important coding standards should be in this document and the rest in the documentation area. > I like the idea of "real and sub commitors" > But think that if we want to go that way we need to enforce > this with real access rights to the cvs (here speaks a person > who's greatest hack was the creation of the speeltuin module) Maybe, but we have to maintain those access rights. And it is not very welcome to newcomers. We are saying: "yes, help us to create great software, but we are not trusting you". We should give newcomers the feeling to be responsible for their actions and that we will give them the benefit of the doubt. > > * @param state Description of parameter > > * @return expected return values > > */ > > private static final int foo(int arg1, int arg2) > bad example :) > > It's always fun to show how not to program. maybe a link to > http://mindprod.com/unmain.html is on it's place? > > > /* Generally use the 8-space rule */ > 4 spaces? No it is the 8-space rule for line wrapping. See the Sun standards "Line wrapping for if statements should generally use the 8-space rule, since conventional (4 space) indentation makes seeing the body difficult." > > arg1 = 10 + some_func (arg1, arg2); /* > Use space around operators */ > Never in mmbase code Is this all you could find in the style example? I really did my best to show that I don't care a lot about style :) > > The email message should start off with a log message, as > described in > > "Writing log messages" above. The patch itself should be in unified > > diff format (e.g., with "cvs diff"). Send the patch as an > attachment, > > with a mime-type of text/x-diff, text/x-patch, or > text/plain. (Most > > people's mailreaders can display those inline, and having > the patch as > > an attachment allows them to extract the patch from the message > > conveniently.) > > I don't see the point in using patches. the easiest way of > testing if something works is just to replace the file/files > sent. People can then view the diffs in there favourite > editors. asking for patches makes the process to difficult. > perhaps in the bug tracker we need to make it possible to add > patches. that fix the problem. > > > It is normal for patches to undergo several rounds of feedback and > > change before > > The feedback is usually about the documentation or chosen > approach not about the actual code I tried to pick extreme measures for the document to show in what way the commuity can go. I hope we are not going to introduce the whole patch/feedback stuff, but we have to clarify to a newcomer how we want to receive the changes. > > The "Patch Manager" Role: > > ------------------------- > with commitors / sub commitors the role of the patch manager > is a bit weird but it's good to have somebody watching the process The role shows that there is one person in the community who is responsible to help newcomers with their changes and that there is someone who will respond to them. Nico _______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
