Marion, Sounding really good, but I hope the "limitations do not restrict our futures"
To clarify, You said you did not understand my line I can still progress the matter but presenting a possible specification, some detailed requirements or research that specifies relevant tiddlers that make coding the solution much more straight forward. What I am saying is although I am not yet at the skill level to build push able items, I am capable of the above input to a change request, making it easier for the developer to action. We should encourage others to do this support work as well. Regards Tony On Wednesday, June 13, 2018 at 8:50:58 PM UTC+10, PMario wrote: > > On Wednesday, June 13, 2018 at 4:21:48 AM UTC+2, TonyM wrote: >> >> This all sounds great. Perhaps you have addressed this but as a super >> user rather than developer, if I see or submit a feature I would really >> like, but do not have the dev skills to implement it >> > > The feature-request > <https://gitlab.com/tiddlywiki.org/feature-request/issues?sort=weight&state=opened> > > section, I did propose is meant to be part of this workflow. ... > > At the moment we have ~500 feature requests in our 600 item issue-list. > That's a big problem. Because if someone looks at it, they may think. > "This project is broken". Which is not true. There are just a lot of > feature requests. ... Which means there is a lot of interest ... > > So enabling voting and discussion, in an area, that doesn't "clash" with > the bug-list, may raise the possibility that developers actually pick up > and implement features, where we know, that they will benefit many users. > ... > > ------------ > > About skills. .. At the moment it's not possible, to allow a newbee > developer to publish the simpliest changes. Even if it is ... fixing some > typos. > > Because everything is 1 big monolythinc "beast". ... It's easy to create > side-effects, that may break "the core" ... So every simple change has to > go through the same review cycle as "core" changes. > > Which is slow and sometimes frustrating for new developers. ... That's > why, the proposal is to split things up in a sensible way. eg: > > User documentation ... Can be updated within minutes!!! > - Community Links > - Extended Examples > - HomePage - Landing Page > - .... > > Middle Gournd ... We will see?! > - Community Plugins > - Editon Templates > - Themes > > Reference documentation ... changes with a new Release > - It's important, that the the reference info is in sync with the core > - core translations > > > >> I can still progress the matter but presenting a possible specification, >> some detailed requirements or research that specifies relevant tiddlers >> that make coding the solution much more straight forward. >> > > I don't understand this paragraph. > > >> It would be nice not only to allow this type of content into a request >> but to also encourage it , in part because if someone wants something, or >> likes something they are actually more likely to actually help it happen. >> > > That's 100% right. ... Developers are humans too :) ... And there is a > much better chance, that I implement something, that I also would like to > have, as something, that I don't need or don't like. .... BUT .... > > My decision may change, if I see, that a feature, I thought is not needed, > got 200 up-vots. ... So implementing it, would increase "fame" qute a bit. > Which isn't a bad thing ;) > > >> This could simplify the development process and increase the throughput >> by crowd-sourcing some of the effort. Perhaps being able to rate each >> feature with a complexity (how complex the change is) and maturity level >> (How close to completion) could help. >> > > With the current GitHub setup, it's not possible, that "users" add / > change labels to issues. Only the project owner can do this. > > With my proposed setup, that changes. The "Reporter > <https://docs.gitlab.com/ee/user/permissions.html>"-role is designed to > be used for this type of work. So "reporters" can help developers with some > admnistrative work. > > ------ > > The next role "developer" can already push to "non-protected" branches. > ... A non-protected branch has the possibility to trigger an automated > "build and publish" process. ... > > At the moment this would be similar to the creation of a prerelease. .. > Which only Jeremy can do. ... > > I hope that makes sense. > > have fun! > mario > > > > -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/tiddlywikidev. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/f7613dec-2590-46ab-971a-feb80959ed45%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
