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.
