Preparing TW for the next step

[Diego Mesa]

Hello TW Devs,

I have a delicate question/comment/discussion to pose to Jeremy and the community. 

As we know, the development priorities are set entirely by Jeremy, and (at least most recently) new major features get developed by him as they become relevant to Jeremy's use and development of TW for various commisions (I don't know how true this is historically, or even generally, and I mean no judgment or offense by saying this). Other features get added slowly and only after persistent pushing by dedicated members (like aspects of the keebord plugin finally making it in!). 

There has been a lot of talk about opening up TW so that other people can handle accepting pull requests, closing tickets, reviewing new features, etc. There was even a brief period where we tried out gitlab, discussed a workflow there, etc. I am not sure what happened this time. I am very interested in seeing this happen, not so I can try and influence its direction directly - I am only an amateur TW developer and intermediate user - but so that TW can open up to "the next level". For example, I'd like to prepare TW to be able to participate in the next Google Summer of Code! (only as an example), or to be used as a software development class project for a group of students at a university where they fix bugs, add features that the community needs, etc! Or to be subject of a weekend hackathon by a group of people! 

We can even imagine simplifying while expanding the supported editions of TW:

1. Bare-Bones
   
2. Feature Rich
• Comes loaded with many plugins making it easier for new users to "get started". 
  
3. Niche:
• Writer
• Student/Researcher
• Dungeon Master/Gamer
• etc. - These will probably just differ in style/pre-loaded content, not really functionality. 

When TW has:

• Development goals/features that are:
1. planned and fleshed out ahead of time (think github milestones, roadmaps, etc.) 
2. prioritized by the community (think github stars/votes in comments, etc)
   
• A responsive group of developers to handle a growing community of bug reporters and contributors

I think it can really grow into its own! 

----

Some context: In my time in GG I see motivated talented people come in, want to contribute, show us what they have and eventually life takes over and they move on and at best were left with a plugin, and if we're lucky the plugin is on github and not lost as an attachment in GG. I want to make sure TW is in a place to take full advantage of talented peoples limited time! 

Any and all comments are welcome! 

[TonyM]

Diego Mesa,

Jeremy, I hope you can respond to this and I hope you don't mind me speaking of you, I hope you set the record strait where I am in error.

Diego, I empathise with your position. I would however characterise Jeremy's involvement from two perspectives

• one a high degree of sense of ownership, which he deserves and yet he is very open to community influenced change 
  
• and tends to act as a quality control gateway (and limiting gate)
  

These aspects of Jeremy's knowledge and experience is essential to the success of tiddlywiki so far, but it is true it makes him a single funnel, 

and thus you can see why the results of key changes tend to be influenced by his perspective.

The truth is I am making a personal and professional commitment to tiddlywiki, and would like to be able to effect more change than is occurring, 

eg; My Git Hub issues that remain un-actioned, and conceptual ideas I have trouble getting acknowledged

Not withstanding it does need this Quality control and vision of Jeremy or a set of his delegates or collaborators.

For me personally, I deeply understand Jeremy's vision, yet I too am a conceptual thinker and I see little changes that could make substantial differences, that is I would like to be involved with conceptual changes. 

I want to contribute to the Vision, Yet this understandable funnel of Jeremy, is restricting change. It also requires me persuading Jeremy that my input be taken seriously (not withstanding I sometimes get it wrong)

Sometime, I have difficulty persuading Jeremy, Yet know a number of others in the community share the need for that same change, then I am shy of taxing Jeremy's Time, or having extended length conversations trying to persuade him. A Number of which just get left open and un-auctioned, because understandably Jeremy does not have the time to attend to all of these, especially when the argument is subtle or complex, and it does not seem important to him.

I do think we need to build the collaborative top level here, asking Jeremy to delegate or distribute more of the effort and control. 

I agree that we should expand

• Development goals/features that are:
1. planned and fleshed out ahead of time (think github milestones, roadmaps, etc.) 
2. prioritized by the community (think github stars/votes in comments, etc)
   
• A responsive group of developers to handle a growing community of bug reporters and contributors

But I would also suggest if Jeremy can distribute some of his current roles, it will be necessary to deconstruct what Jeremy does himself, for example;

• Vision and core change
• Quality Control and best practice code
• Maintaining modualarity
• Selection and Development of key editions
• Selection and Development of key plugins
• Management of server and platforms

There is no way one person can take on all that Jeremy can/does do at present

It needs something I call "Collaborative Distributed leadership". There are people like Mario, Evan, Eric are clearly qualified to take on code and release Quality assurance, I would claim insight to making documentation and examples understandable and proposing small changes for great benefit. You can see how Josiah is our best "tiddlywiki champion" , community organiser and helps us "get real". Yourself and many others are also qualified in one or more areas and I would acknowledge here with more time like David Giffords Toolmap.

One key enabler in a "Collaborative Distributed leadership" is understanding which areas are independent or interdependent, and when interdependent how to establish a review process, and who is qualified to perform this.

Sincerely

Tony

[Mohammad Rahmani]

Hello Diego,

 I am totally agree with you! I think TW can use the experience form many other successful software in this way. TW in 2019 is not the small code of 2004 and needs more people to be involved from different areas of technology. Still I respect the Jeremy rights and wishes. He  can have control on every aspects, but he can acts as project manager! and use the huge capacity of many talents, interested experts, ... who wish to help, improve TW.

Cheers

Mohammad 

[Diego Mesa]

Absolutely! I also respect everything Jeremy has done, is doing and will continue to do for TW. Being the owner and maintainer of a large/popular open source project is in many ways a painful and rewardless job! 

[Jed Carty]

I don't understand the comments about Jeremy having a high degree of ownership. I don't know of any proposed editions that were actually submitted that have been rejected. When I made the resume edition it was accepted almost immediately. The only times he has hesitated or said no is when something would prevent backwards compatibility in the core or it would be better as an external plugin to maintain the flexibility of tiddlywiki. I think that he has supported the idea of having more than just the empty edition available for download on tiddlywiki.com, but no one has created and submitted a editions for consideration yet.

From what I can tell most of the perception comes from people thinking that there is some barrier and not trying and then no one sees anyone succeeding because very few people try and then they assume that they are right about there being some barrier.

[Mohammad Rahmani]

Jed,

 What Diego said is, a large and popular project cannot be maintained by ONLY one person! That's all.

His proposal states to involve more interested and expert people in development!

Cheers

Mohammad

[Diego Mesa]

Jed,

If you look at:

• issues on github
• long abandoned contributions/plugins dying slow deaths on google groups
• experiences trying to get a new person to try TW

I'd say there is quite a bit of evidence of "barrier to entry" in many senses. 

Just as an example, look at:

• all of the conversations Evan Balster had in this group, his plugin, and this PR: https://github.com/Jermolene/TiddlyWiki5/pull/3072
  
• All of Tobias' PR: https://github.com/Jermolene/TiddlyWiki5/pulls/tobibeer

Both Evan and Tobias are "inactive" right now, and there is no clear plan on what to do with all of their excellent work. 

All I am saying is that a project like this, that we all love and appreciate, should be in the best possible position to take advantage of highly skilled people giving limited amounts of time.

[@TiddlyTweeter]

I agree *very much* with Jed.

In particular, Mr Ruston's concern with backwards compatability is ace and a neat near 9.95 out of 10. I hope your angle won't mess that up. It could.

I also agree that the dev side is not so populated. There simply are not enough commited devs. (I'll never be one)

IMO you have to prove relevance.

Erwan and Tobias are red herrings--they mainly not here--that is not aversion to TW--merely off doing their own thing.

I DO think a more open context could help cope with the many standing PRs. BUT not a free-for-all.

SO somewhere is "middle-ground" I hope.

Not sure this makes sense. But I'd say that mr JR is "long in the tooth" ... and still basically responds to strong knocks on heaven's door. https://www.youtube.com/watch?v=gazW7MOqHzQ

Josiah

[TonyM]

Diego,

There are a few crossed wires here. I agree with the overall meaning in this thread however Jed is commenting on the area of editions and using plugins to avoid core changes for "edge Cases". 

The fact is we can all do this right now, generate special editions, with any level of design, hacking and development.

Jeremy has embraced suggestions which open tiddlywiki to hackability, thus permitting editions and plugins, even macros to get past limitations. ie opening up the possibilities. But as great as he is he is but one man, and we will all benifit if we can open the funnel.

Regards

Tony

[Diego Mesa]

Let me further emphasize my only point:

I dont think Evan and Tobias are red herrings (especially because Tobias was here for a long long time). 

My entire point is this: We should structure TW on github, so that we can:

1. Maintain backward compatibility - Priority number 1
2. take advantage of highly skilled people giving limited amounts of time. - Priority number 2
   

It doesn't make sense that only long-term committed people can contribute to the TW codebase. Many talented people can spend 1-2 weeks overhauling the popup mechanism for example, and then move on with their lives...

[TonyM]

I total support your arguement.

Broader contributions from the user community to documentation could also happen if we had some nice instructions and more processing of the changes.

Regards
Tony

[Diego Mesa]

Jeremy I'd love to hear your thoughts if you get a chance!

[Diego Mesa]

A great step in this direction is addressed in this GitHub issue:

https://github.com/Jermolene/TiddlyWiki5/issues/3623

[Jeremy Ruston]

The other critical issue is this one about moving the TiddlyWiki5 repo from my Jermolene GitHub account to the “TiddlyWiki” shared organisation. It will allow us to use finer grained permissions to delegate more of the project activities:

https://github.com/Jermolene/TiddlyWiki5/issues/3114

Best wishes

Jeremy

--
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 tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
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/2a649e79-f36f-4b5c-9813-02e01668b0ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.