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 ture. 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 > 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/3c0a446d-7218-4aa9-87d8-9a9b0638c696%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
