With the upmost respect for Jeremy, has anyone considered forking the 
project and maintaining a more public facing roadmap and feature list? With 
a focus on: organizing and involving others in the direction and decision 
making I think TW can really expand! 

That fork would be "downstream" from the original, taking all of its 
features, and the original TW can "pull" anything Jeremy deems worthy. The 
downstream maintainer should be a trusted and longtime member of the 
community, of course.

There is much precedence for this kind of relationship in the open source 
community. There are already some examples in TW with NoteSelf and 
Maarfapad. I want a more centralized, community focused edition of TW, 
similar to the early relationship with Debian Linux and Ubuntu Linux, 
CentOS and Redhat, etc.

I'd like to see a public, current, and *community driven roadmap and 
feature list, and a responsive set of core developers that have direct 
access to accept pull requests, etc*. As Ive stated before, I want to see 
TW infrastructure be able to support a "Google Summer of Code" 
developer/team, or even a "Senior Project" team of software developer 
students at a university. 

Something I'd like to see on the roadmap: plugin update notifications. As 
the core is always kept small and lean, plugins are a central part of the 
TW ecosystem, but currently we have to go to to google groups, search, find 
one as an attachment or a link to tiddlyspot (sidtenote: pray tiddlyspot 
never goes down as much excellent work is there!), hope it works, drag it 
over. Some day you have to remember to go back and check the source to see 
if theres been an update, etc.

Objections I foresee to "downstream proposal":

   - You're free to do this yourself
      - Yes that is true - if I could, I would. It can also be dismissive 
      to point this out to someone making suggestions to the community.
      - We're happy with TW as it is
      - Ok - great. Then this thread is not meant for you
   - We dont want TW to break backwards compatibility
      - This could and should be a core concern for whatever "downstream" 
      projects exist as well, using version numbering to signal backwards 
      compatible changes
      
Best,
Diego

On Saturday, November 2, 2019 at 10:42:39 AM UTC-5, Mohammad wrote:
>
> Thank you all for your reply and thoughts.
>
> --Mohammad
>
> On Saturday, November 2, 2019 at 3:45:55 PM UTC+3:30, Jeremy Ruston wrote:
>>
>> Hi Everyone
>>
>> The “Road Map” tiddler was added at some point because somebody had asked 
>> for it. Of course, it’s troublesome to remember to update it, so it’s 
>> fallen by the wayside.
>>
>> I think the roadmap today is driven by the needs of Jeremys business 
>> projects and the pull-requests by insistent contributors. 
>>
>>
>> That’s broadly correct. I think there’s probably at least four categories:
>>
>> * Pull Requests from others
>> * Fixes/features in response to requests here on the mailing list
>> * Bug fixes
>> * Changes arising from Federatial’s commercial work for clients (much of 
>> which is in plugins of course)
>>
>> Best wishes
>>
>> Jeremy
>>
>>
>>
>> As you can see in the PR-list BTC 
>> <https://github.com/Jermolene/TiddlyWiki5/pulls/BurningTreeC> has a lot 
>> of open PRs that all contain keyboard related improvements. Some of them 
>> have been *rewritten *3 times already.
>>
>> I myself am most interested atm in improving the TOCs, the navigation 
>> <https://github.com/Jermolene/TiddlyWiki5/issues/4354> and saving and 
>> retrieving stories <https://github.com/Jermolene/TiddlyWiki5/issues/4319>in 
>> a "compatible" way. 
>>
>> There is also an important one that deals with paragraph handling 
>> <https://github.com/Jermolene/TiddlyWiki5/pull/4290> and TW html 
>> generation in general. ... all of them are really low level! 
>>
>> The last example won't be even seen by users, but will make a big 
>> difference for the whole project. Especially simplify personalisation and 
>> theming. 
>>
>> --------------
>>
>> As TT pointed out, very often it is better to start with plugins, than 
>> call for core implementation. ... We basically have to maintain core 
>> functions "for ever". So they should be "bullet proof" and backwards 
>> compatible, because they will be very hard to remove.
>>
>> Experimenting with my interests mentioned above, I did find out, that a 
>> lot more tests are needed. IMO implementing "low level function" in the TW 
>> navigation mechanism is like "spine surgery".  We have to be sure, what's 
>> going on. ... On the way I did also find some problems #4349 
>> <https://github.com/Jermolene/TiddlyWiki5/issues/4349> and some fixes 
>> #4353. <https://github.com/Jermolene/TiddlyWiki5/pull/4353>
>>
>> So if we want to improve "the core" we must have the "big picture" in 
>> mind. New features need to be as useful as possible for everyone. 
>>
>> just some thoughts
>> mario
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "TiddlyWiki" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected].
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/tiddlywiki/ac282a8d-2144-4e8d-ab8a-ca6ebc530cf6%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/tiddlywiki/ac282a8d-2144-4e8d-ab8a-ca6ebc530cf6%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/b55abc94-e612-44f7-886c-90bbef021208%40googlegroups.com.

Reply via email to