I've had a good at a first version of guidelines The idea of this text is that it would be linked to or part of https://github.com/TiddlyWiki/tiddlywiki/blob/master/README Please help me finalise this so we can do a better job of helping developers contribute to the TiddlyWiki project.
######################################################################################## "Pull requests for feature requests/bug fixes are being accepted for this project. Note pull requests will only be accepted into the core if accompanied by tests. Also there are certain situations where a pull request may need further discussion or be delayed before actioned. These include * impacts on backwards compatibility * impacts on existing tests (all unit tests should pass after a merge) * provides new functionality that is too specific to a certain type of TiddlyWiki user * code results in a visible change to the appearance of TiddlyWiki * creates discussion around the naming of certain parameters * the TiddlyWiki code is being stabilised in time for a new release and is not accepting new features If no tests existed for the given functionality previously, please include these in your contribution to ensure that the TiddlyWiki code base is as reliable as possible going forward. Any pull requests without tests will not be folded into the core codebase. If you are unable to write tests yourself, someone will need to write them on your behalf. This could be another github user or one of the TiddlyWiki repository owners. Tests are written in qunit (http://docs.jquery.com/Qunit) It is the job of all TiddlyWiki contributors to help with providing guidance if needed on writing tests. Please send your pull request without tests and discussion should happen. Existing tests can be found in the directory https://github.com/TiddlyWiki/tiddlywiki/tree/master/test/js ######################################################################################## On Jun 24, 8:04 pm, PMario <pmari...@gmail.com> wrote: > On Jun 23, 9:36 am, rakugo <jdlrob...@gmail.com> wrote:> My question is where > does the line get drawn about what can be pushed > > into the project as we have a duty to project the code base for > > existing users. > > Since Github has Github pages, I think it would be nice to have some > links there. > Links to tiddlywiki.com - tiddlywiki.org for users > Link to eg: "Info for developers" which is part of Github pages or > Github wiki, which contains the ruleset defined below. This also > includes links to tiddlywiki.org and its relatives. > > > For instance, I could create a pull request that changed the default > > theme of TiddlyWiki. The core project commiters might reject this > > change, and I might be put off to ever sending pull requests to > > TiddlyWiki code, as in the current world it was not clear when I > > submitted such a pull request that it had any grounds to be rejected. > > I think, this can be avoided, by presenting a link to existing TW > themes, in the TiddlyWiki GitHub homepage / wiki > > > In my opinion, we should allow any pull requests that enhance or > > improve the existing codebase on the basis that they provide unit > > tests. > > Since TW doesn't draw a line, which core functions are "low level" and > which functions are "dev level", IMO discussion will be allways > needed. Propper unit tests should make it easier, but it shouldn't be > a free ticket. > > > By this I propose we might accept the following things: > > * A javascript function is refactored into 2 functions to allow better > > reuse > +1 > > * The code is cleaned up to be more readable > +1 > > * An existing function/macro is enhanced/extended to accept further > > arguments (on the basis of improving the offering) > > I would want to discuss, the name of the new parameter. If a wrong > name will be accepted, it will be hard to fix it later. There should > be some kind of best practice for TW variable names anyway. > > > * The code is cleaned up to work in different environments (for > > instance TiddlySpace run some of the TiddlyWiki code in nodejs a > > server side implementation of javascript or code might be packaged up > > into a jQuery plugin to allow more reuse in other projects > > +1 > > > Situations where we might reject or want further discussion in groups > > could be > > * The code introduces a new core macro to the code base > > * The code breaks a test > > * the code changes how the api works (backwards compatibility > > concerns) > > * the code results in a visible change to the appearance of TiddlyWiki > > +1 > > > It would be great if we could come up with a set of guidelines for > > contributing to the TiddlyWiki project and link to it / include it in > > the git repository. I think it is vitally important that we continue > > to build on the momentum that we seem to have gained so far. > > +1 > > -m -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to tiddlywikidev@googlegroups.com. To unsubscribe from this group, send email to tiddlywikidev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.
