Should TiddlyWiki consider moving to GitLab?

[Simon Huber]

Hi, with the rumors or facts about MS buying GitHub I've seen projects discussing moving over to GitLab

Because TiddlyWiki5 already wants to move to another repo, I'd like to ask if GitLab is something that could be considered, too?

BTC

[PMario]

On Monday, June 4, 2018 at 8:50:56 AM UTC+2, Simon Huber wrote:

Hi, with the rumors or facts about MS buying GitHub I've seen projects discussing moving over to GitLab

 ... Let's wait and see, when they make something official. ...

 

Because TiddlyWiki5 already wants to move to another repo, I'd like to ask if GitLab is something that could be considered, too?

GitLab is definitely an option. ... but ... There is GitLab Inc, and GitLab the product.

GitLab the product is open souce, and you can host it yourself. .. If you want to be in hosting business.

GitLab Inc. is a company that runs GitLab.com. Which is a hosting platform similar to GitHub (see the H). ... So what happens now to GitHub can also happen to GitLab Inc., the company!

... But we (TiddlyWiki community) have a functionality problem. I'm not sure, if GitLab can fix it.

Jeremy wants to keep the repository structure. .. Which in my opinion can't be managed with github. ... I personally can't find a way to configure, write-access on the directory level. .. The only way github allows, is per repositroy access configuration. ... Which Jeremy doesn't want. ... So back to step 1.

-------------

IF MS aquires Github, we will need to see, how they behave.

It may be possible, that they open source the whole thing. So, there may be more possibilities, as now. Some Enterprise edtion features may be free in the future. ... see may be!

They definitely will create closer integration with Microsoft Accounts. .... Which not necessarily is a good thing (for me)

--------------

At the moment, I'd say, we have a closer look at GitLab workflow, which is 90% the same, since git is the underlaying technology. The existing possibilities are more advanced as GitHub at the moment. ...

So we can create a new group there. tiddlywiki ... Is already taken!! So we would need to get it back.

I did grab "tiddlywiki5" and "tiddlywiki.org"

I'll invite you, to the .org and we can play around with it, if you want.

I can also invite you to https://github.com/tiddlywiki-org/ at GitHub, if you want.

have fun!

mario

[Simon Huber]

On Monday, June 4, 2018 at 8:50:56 AM UTC+2, Simon Huber wrote:

Hi, with the rumors or facts about MS buying GitHub I've seen projects discussing moving over to GitLab

 ... Let's wait and see, when they make something official. ...

 

Because TiddlyWiki5 already wants to move to another repo, I'd like to ask if GitLab is something that could be considered, too?

GitLab is definitely an option. ... but ... There is GitLab Inc, and GitLab the product.

GitLab the product is open souce, and you can host it yourself. .. If you want to be in hosting business.

GitLab Inc. is a company that runs GitLab.com. Which is a hosting platform similar to GitHub (see the H). ... So what happens now to GitHub can also happen to GitLab Inc., the company!

Yes, will be interesting to observe if/how things change 

... But we (TiddlyWiki community) have a functionality problem. I'm not sure, if GitLab can fix it.

Jeremy wants to keep the repository structure. .. Which in my opinion can't be managed with github. ... I personally can't find a way to configure, write-access on the directory level. .. The only way github allows, is per repositroy access configuration. ... Which Jeremy doesn't want. ... So back to step 1.

Is this the functionality problem?

What do you mean with repository structure? The folder-structure from the base-level up ... write-access for some only on some directories? 

-------------

IF MS aquires Github, we will need to see, how they behave.

It may be possible, that they open source the whole thing. So, there may be more possibilities, as now. Some Enterprise edtion features may be free in the future. ... see may be!

They definitely will create closer integration with Microsoft Accounts. .... Which not necessarily is a good thing (for me)

--------------

At the moment, I'd say, we have a closer look at GitLab workflow, which is 90% the same, since git is the underlaying technology. The existing possibilities are more advanced as GitHub at the moment. ...

So we can create a new group there. tiddlywiki ... Is already taken!! So we would need to get it back. 

I did grab "tiddlywiki5" and "tiddlywiki.org"

I'll invite you, to the .org and we can play around with it, if you want.

Ok, sounds fun. Cannot find them on GitLab atm, I'm BurningTreeC over there, too 

I can also invite you to https://github.com/tiddlywiki-org/ at GitHub, if you want.

What are the things to explore/do there? 

Simon 

[PMario]

On Monday, June 4, 2018 at 11:39:00 AM UTC+2, Simon Huber wrote:

... But we (TiddlyWiki community) have a functionality problem. I'm not sure, if GitLab can fix it.

Jeremy wants to keep the repository structure. .. Which in my opinion can't be managed with github. ... I personally can't find a way to configure, write-access on the directory level. .. The only way github allows, is per repositroy access configuration. ... Which Jeremy doesn't want. ... So back to step 1.

Is this the functionality problem?

What do you mean with repository structure? The folder-structure from the base-level up ... write-access for some only on some directories? 

Exactly.

-m

[PMario]

On Monday, June 4, 2018 at 11:39:00 AM UTC+2, Simon Huber wrote:

I'll invite you, to the .org and we can play around with it, if you want.

Ok, sounds fun. Cannot find them on GitLab atm, I'm BurningTreeC over there, too 

I'll invite you.

 

I can also invite you to https://github.com/tiddlywiki-org/ at GitHub, if you want.

What are the things to explore/do there? 

How we can create a new structure, that is easy for devs and users. ...

First thing needs to be: Move the documentation to the community, so it can be independent from the core.

-m

[PMario]

On Monday, June 4, 2018 at 12:44:05 PM UTC+2, PMario wrote:

I can also invite you to https://github.com/tiddlywiki-org/ at GitHub, if you want.

What are the things to explore/do there? 

How we can create a new structure, that is easy for devs and users. ...

First thing needs to be: Move the documentation to the community, so it can be independent from the core.

At the moment we have a CLA ... With a more open community we'll also need a Code of Conduct, where we write down, what we expect from discussions about different topics.

I did have a look at other open source projects. ... But all of them, describe in detail and long lists, what you should _not_ do. Lists are getting longer and longer, once users start to argue: "You didn't mention this and that and blablabla ... IMO that doesn't make sense to me.

I want to have a CoC that describes the positive behaviour we want to have. ... And everything which isn't mentioned there, has a high chance to be "wrong behaviour".

Just one of the examples, that could be discuessed there.

have fun!

mario

[PMario]

On Monday, June 4, 2018 at 11:39:00 AM UTC+2, Simon Huber wrote:

I did grab "tiddlywiki5" and "tiddlywiki.org"

I'll invite you, to the .org and we can play around with it, if you want.

Ok, sounds fun. Cannot find them on GitLab atm, I'm BurningTreeC over there, too 

I did add you as Master, which has almost all possibilities.

-mario

[Jeremy Ruston]

> Hi, with the rumors or facts about MS buying GitHub I've seen projects discussing moving over to GitLab

> Because TiddlyWiki5 already wants to move to another repo, I'd like to ask if GitLab is something that could be considered, too?

If you mean the hosted version of GitLab, I wouldn’t see much difference between that and GitHub; they’re both commercial organisations with their own goals that may not always align with ours. (Back in 2008 I was initially against the migration from our own self-hosted VCS to GitHub, for background).

Jeremy wants to keep the repository structure

To be specific, I want to retain the “monorepo" structure for TiddlyWiki5: a single repo that contains all the core components, so that they are automatically in sync with one another. That includes: the core code, the core plugins, and the core reference documentation.

If we want to give translators (say) write access to a particular plugin then we’d instead ask them to maintain their own repo of that plugin, and we’d pull the changes in when they’re updated.

Best wishes

Jeremy.

[Stephan Hradek]

Am Montag, 4. Juni 2018 08:50:56 UTC+2 schrieb Simon Huber:

Hi, with the rumors or facts about MS buying GitHub I've seen projects discussing moving over to GitLab

For the records: "13,000 Projects Ditched GitHub for GitLab Monday Morning" https://motherboard.vice.com/en_us/article/ywen8x/13000-projects-ditched-github-for-gitlab-monday-morning.

I moved my only own project from Github to bitbucket.

[PMario]

Hi Stephan,

Imported repositories per hour ... since it started to get crazy :) 

It's interesting, to see how the overal page performance behaves. .. I did do a lot of testing since monday, where I did hit a lot of timeouts. ... Now, it seems they are up to the job ... almost ;)

-m

[Diego Mesa]

Hey Mario,

Correct me if Im worng, but cant we just split the repo into the part Jeremy wants people to help with, and have that be a submodule of the main project that only he can access? 

Diego

[PMario]

On Thursday, June 7, 2018 at 11:22:28 PM UTC+2, Diego Mesa wrote:

Correct me if Im worng, but cant we just split the repo into the part Jeremy wants people to help with, and have that be a submodule of the main project that only he can access? 

use google and search about submodules. ... extremely error prone.

-m

[Jeremy Ruston]

Hi Diego

Correct me if Im worng, but cant we just split the repo into the part Jeremy wants people to help with, and have that be a submodule of the main project that only he can access? 

My point wasn't about access control. It was that I am not in favour of splitting the TW5 repo up (e.g. moving each translation to its own repo). The reason is that it becomes harder for users of the repo to manage, making sure that they have cloned the right repos, and that they are all synced together. The current state will always be in sync, but it is hard to, say, reconstruct what the repos looked like on 11th May 2016. This is a somewhat controversial area but this "monorepo” philosophy is widely practiced for large scale projects (e.g. Google stores billions of lines of code in a single repo).

In terms of submitting plugins to the library I believe that we need to primarily focus on engineering a flow that is suitable for people who don't use GitHub (e.g. letting plugin writers publish their stuff to their own URL, and have a process to pull changes into the core repo). In practice that means that we need an API for submitting plugins or other items to the library. Then it's trivial for GitHubbing terminal dwellers (like me!) to engineer whatever system they want for publishing their plugins.

Best wishes

Jeremy

Diego

On Thursday, June 7, 2018 at 5:17:33 AM UTC-5, PMario wrote:

Hi Stephan,

Imported repositories per hour ... since it started to get crazy :) 

It's interesting, to see how the overal page performance behaves. .. I did do a lot of testing since monday, where I did hit a lot of timeouts. ... Now, it seems they are up to the job ... almost ;)

-m

--
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/97ba8981-b3ee-4e9f-bb96-7b28d2db2268%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[@TiddlyTweeter]

Ciao Jeremy and all

This is a comment slightly from a weird position (probably) from your point of view. I'm not thinking here as a developer. I'm thinking as a social anthropologist.

I am reading several discussions at the moment about proposals for innovation in development process, documentation and addressing user needs better.

I am, frankly, feeling some of this effort could be wasted because IMO the single biggest danger with TW is yet more fragmentation. The GitHub side is the most integrated and consistent at the moment.

Out in the world of end-users some of us are struggling to join-the-informational-dots of the scattered resources so everyone knows what is where. just finding things, plugins, tutorials, example TW etc is almost a full-time job.

On the dev end my concern is: could the desire to improve actually have unintended consequences that actually increase fragmentation?

Just thoughts
Josiah

[PMario]

On Friday, June 8, 2018 at 11:12:56 AM UTC+2, @TiddlyTweeter wrote:

...

I am, frankly, feeling some of this effort could be wasted because IMO the single biggest danger with TW is yet more fragmentation. The GitHub side is the most integrated and consistent at the moment.

You are right. At the moment, we face a lot of fragmentation, because there is no "easy" ways to create something, that is tightly coupled to tiddlywiki.com, but is outside of the release cycle of tiddlywiki.com

So users use what they know best, or they introduce a 3rd party platform, they think could be useful. ... That's great but causes fragementation!

We have many different resources, that are great. So over time as things get bigger, because they are useful. .. It starts to get a full-time job for 1 user, because the different elements don't play well together. As Jeremy points out there should be an eg: tiddlywiki.org umbrella! which keeps all elements loosely coupled.

eg: GifMex'es tw-dynalist is a great resource:  https://dynalist.io/d/zUP-nIWu2FFoXH-oM7L7d9DM ... But he had to tell the community, that he's on holyday, so the list won't be extended for several days! ... That's a problem. ... Not the holydays, but the "helpnessless" of the community. ...

I personally think, that this is an "access control problem" ... At the moment we can't create a "workplace" for new projects that are outside of tiddlywiki.com but still belong to the tiddlywiki-community. 

We simply can't allow everyone to write to a repository that contains the core software, without reviewing the content. But not everyone can be, or will want to be involved in every aspect of the community. ... That's why we need "groups" with different possibilities.

So there should be a possibility to have: "TiddlyWiki Toolmap" group, that is "self-governed" and has the possibility to publish to tiddlywik.org/community/editions/toolmap.html ... The path is an example only!

 - The release cycle is maintained by group members

 - The layout is maintained by group members

 - Devs should provide a template to get started

 - Devs should provide some basic rules, that group members can adopt and / or change  ...

 - Group members should vote on content, that is ready to be published.

 - ... BUT .... Publishing is done by a robot. So group members don't need to know, what exactly needs to be done.

It should just work!

 

Out in the world of end-users some of us are struggling to join-the-informational-dots of the scattered resources so everyone knows what is where. just finding things, plugins, tutorials, example TW etc is almost a full-time job.

As I wrote. I want to have it under the tiddlywiki-community umbrella. Preferably tiddlywiki.org

 

On the dev end my concern is: could the desire to improve actually have unintended consequences that actually increase fragmentation?

I'm trying to solve this. I'll publish more info on sunday and hopefully have some 3-minute videos too

have fun!

mario

[@TiddlyTweeter]

PMario ...

eg: GifMex'es tw-dynalist is a great resource:  https://dynalist.io/d/zUP-nIWu2FFoXH-oM7L7d9DM ... But he had to tell the community, that he's on holyday, so the list won't be extended for several days! ... That's a problem. ... Not the holydays, but the "helpnessless" of the community. ...

I want to comment more about this in some detail because its important to functional dynamics.

And to get away from the idea somehow you people on GitHub know what you are doing beyond GitHub. There is little evidence you do! :-).

I been around TW now long enough to see an innovation when its there. I seen serious initiatives on Reddit, on Stack Exchange start and stall. I complained endlessly when I started about "documentation".

Gifford's "Out Of The Blue" initiative on TiddlyToolMap emerged from his own frustration with not being able to find things. And on that he put-his-finger-on-the-issue ... its NOT lack of information, documentation or resources that is the main issue, it is FINDING them.

He has given the start of HOW to find what you need when you need it. His work, far more than anything I have ever seen, illustrates that issue and begins to solve it.

His solution is clunky, imperfect & limited to his time available. It has to be. One person handling masses of info.

I love he is imperfect, limited and can't avoid being clunky. Because he DID it.

So whilst "you" (no pointing) may see a need for all this to be under an umbrella, until such time as you provide both the mechanism and people to do it, I'd say people like David are still our best bet.

So, unless you have a better way formed, better to just say "it's really good!" Which it is.

FYI, I am aware he is time limited and agreed to handle Twitter announcements for him.

Side thoughts, but not entirely irrelevant
Josiah

[PMario]

On Friday, June 8, 2018 at 2:59:31 PM UTC+2, @TiddlyTweeter wrote:

...

So whilst "you" (no pointing) may see a need for all this to be under an umbrella, until such time as you provide both the mechanism and people to do it, I'd say people like David are still our best bet.

I pointed out the dynalist project, because it's a great resource and we as a community should be able to maintain it. Instead of relying on a single user to do so.

Providing the mechanism to maintain this list, independent to the tiddlywiki release cycle is my intention. .. I'm sure it will be imperfect and clunky at the beginning. But I hope we can improve it - together. ...

It's not this single project I'm aiming at. I want to have the possibility to cover all projects listed there, where it makes sense __and__ If their authors want to!

have fun!

mario

[@TiddlyTweeter]

Ciao PMario

I emailed David about this thread ... he replied ...

I would hope that the people to whom you wrote would feel free to use the info in my toolmap to create similar things according to the criteria they set.

A notable point about Dynalist is that its exportable as OPML. Just about the simplest format imaginable. It would be easy to migrate to anything. The really hard work on these resources is getting a starting point. That is there. Needs perfecting, but its there.

PMario wrote:

It's not this single project I'm aiming at. I want to have the possibility to cover all projects listed there, where it makes sense __and__ If their authors want to!

IMO the issue is bang-for-buck.

Meaning "what resources are the least work to garner and hone for the objective?" I think TiddlyToolMap is a pretty much number one because of its scope. Its weak in few areas (like setup), but not many compared to everything else.

Best wishes
Josiah

[PMario]

Hi folks,

you may be interested in a new Video series I did upload today. ... It' about improving Community Communication.

The whole thing is an "experiement", so we can heavily test it, without damaging anything.

It would be nice, if you guyes would request access to the different groups, that are interesting for you

If you are interested in everything .... But just watch the videos and

IMPORTANT.

Starting from video 6 / 7 it t gets more and more developer centric, which is intended!

We need to get the foundations wroking, then we can start to make it easier for end-users.

have fun!

https://www.youtube.com/playlist?list=PLuiC_HFhI4OyUiDGqvzB64mTQTURABjlW

[Diego Mesa]

Mario,

As always - thank you for this. Side note -  I requested access to everything before getting to video 09, so I understand if that is not granted. I can be more specific. My feedback on the videos:

• 02 TiddlyWiki Landing Page Proposal
• I think this is a great idea, and I love your example. I was recently blown away by just how similar the industry standard Scrivener software is (https://www.literatureandlatte.com/scrivener/overview) to TW. But I had a person spend 2 min on their site and 10 min on TW and be confused about what TW IS, let alone what it can DO, to say nothing of HOW. Your landing page demo is a great step in the right direction!
• 03 Feature Request and Voting Mechanism
• I think this workflow is a great idea, allowing users to upvote and developers to weight. This is not only great for developers, but great for the community - they can see what people are working on, and interested in. As a side effect, moving to gitlab (or even a new repo on github) will allow us to kind of "restart fresh", so there aren't over 600 open issues/feature requests that are forgotten and ancient.
• 04 Using email to request a new feature
• a great idea - I didnt see it in 03 or this video, but I would suggest having a template for feature requests, bug reports, etc.
• 05 Governance Model Proposal
• I would love gitter chat and the voice chat! 
• 06 and 07 - Issues and merging for governance model
• Great idea and explanations, but I saw this as more general way for users/developers to contribute - not so much about the specific governance model
• 08 Consensus Seeking and Repo Structure
  
• I really like this structure, especially the plugins, docs, and senatus split! 
• 09 Request Access to Sub-Groups
• I think this is great - it allows the community to prioritize people's contributions in the right way. 

That's all the videos so far. More general comments:

• This system will enable something I think is incredibly important and currently missing: More experienced developers can now mark feature requests or bugs as "beginner", "intermediate", etc. which does great things for encouraging people to get involved! 
• There can now be a gameplan for the future! If we pretend Jeremy/community was able to hire skilled programmers for 1 month - how do we maximize their time? We can now point to the issue board across different groups and say focus here. This is fantastic.
• My biggest question is this - how do we actually get to using this system? If we could identify A) what Jeremy needs to see/do in order to accept this plan and then B) having accepted, what does Jeremy need to see/do to get us there?

[PMario]

On Monday, June 11, 2018 at 11:54:30 PM UTC+2, Diego Mesa wrote:

As always - thank you for this. Side note -  I requested access to everything before getting to video 09, so I understand if that is not granted.

I think, I'll grant Guest or Reporter to basically anyone, that I know from github. .. :) ... For the more "destructive" levels, and new "unknown" names, we will need a short challenge, that lets us connect github user names with GitLab user names. ... I have an idea here.

But for the start you are "Reporter" for the docs and "Guest" for the whole thing. .. This lets us play with the possibilities. ...

 

I can be more specific. My feedback on the videos:

• 02 TiddlyWiki Landing Page Proposal
• I think this is a great idea, and I love your example. I was recently blown away by just how similar the industry standard Scrivener software is (https://www.literatureandlatte.com/scrivener/overview) to TW. But I had a person spend 2 min on their site and 10 min on TW and be confused about what TW IS, let alone what it can DO, to say nothing of HOW. Your landing page demo is a great step in the right direction!

Thx. And since I do already have the "language" part as templates, it should be the first element of the experiment, which gets an automatic build system.

 

• 03 Feature Request and Voting Mechanism
• I think this workflow is a great idea, allowing users to upvote and developers to weight. This is not only great for developers, but great for the community - they can see what people are working on, and interested in. As a side effect, moving to gitlab (or even a new repo on github) will allow us to kind of "restart fresh", so there aren't over 600 open issues/feature requests that are forgotten and ancient.

I actually did a full review of the open issues and found out that are most of them ~450 are feature request. Many of them are still valid and make sense. ... But we as developers have no overview, if it is just 1 person or if there are many users, who would like to have it.

IMO voting is a highly requested feature. ... And if we can link it nicely into a development workflow it is a plus. ...

 

• 04 Using email to request a new feature
• a great idea - I didnt see it in 03 or this video, but I would suggest having a template for feature requests, bug reports, etc.

That's relatively straight forward. ... Just create an issue with some proposed text, and I'll directly add it to the settings. :)

 

• 05 Governance Model Proposal
• I would love gitter chat and the voice chat! 

chat: https://gitter.im/TiddlyWiki/public

voicechat: Will be discord server .... but I'm not very familiar with the admin stuff there. I like it, but I didnt do discord admin work yet. So help would be very welcome here :)

 

• 06 and 07 - Issues and merging for governance model
• Great idea and explanations, but I saw this as more general way for users/developers to contribute - not so much about the specific governance model

That's right.

 

• 08 Consensus Seeking and Repo Structure
  
• I really like this structure, especially the plugins, docs, and senatus split! 

Yea, we will see, how it turns out. We can adjust it further. .. I just found out, how to set repo specific roles. ... So we have a very fine grained control.

 

• 09 Request Access to Sub-Groups
• I think this is great - it allows the community to prioritize people's contributions in the right way. 

I think, it's a great way, to keep focus. Some users may only be interested in 1 or 2 aspects of the whole thing.

 

That's all the videos so far. More general comments:

• This system will enable something I think is incredibly important and currently missing: More experienced developers can now mark feature requests or bugs as "beginner", "intermediate", etc. which does great things for encouraging people to get involved! 

exactly! ... And the cool thing is, If we have users that push a lot of good stuff, we can promote them up to devs and they are able to create the content themselfs. ... Once the review is finished, the community can publish it.

 

• There can now be a gameplan for the future! If we pretend Jeremy/community was able to hire skilled programmers for 1 month - how do we maximize their time? We can now point to the issue board across different groups and say focus here. This is fantastic.

yes.

 

• My biggest question is this - how do we actually get to using this system? If we could identify A) what Jeremy needs to see/do in order to accept this plan and then B) having accepted, what does Jeremy need to see/do to get us there?

At the moment everything is a big experiment. ... Nothing is carved in stone! ...

1 "short term goal" is, to create a CI/CD workflow for the new landing page.

So I can create the next video: TiddlyWik as a static site gnerator

Where I can show the whole development cycle.

 - Forking

 - local development

 - pushing a new feature-branch

 - crate a Merge Request

 - CI/CD builds a preview page

 - After review is OK

 - CI/CD automatically publishes the page.

Since this workflow is basically the same for every other repo ... we basically won :)

-m

[PMario]

On Tuesday, June 12, 2018 at 1:13:25 AM UTC+2, PMario wrote:

 

That's all the videos so far. More general comments:

• This system will enable something I think is incredibly important and currently missing: More experienced developers can now mark feature requests or bugs as "beginner", "intermediate", etc. which does great things for encouraging people to get involved! 

exactly! ... And the cool thing is, If we have users that push a lot of good stuff, we can promote them up to devs and they are able to create the content themselfs.

without the risk to damage, the core components.

 

... Once the review is finished, the community can publish it.

-m

[TonyM]

Mario,

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 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. 

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. 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.

Regards

Tony

[PMario]

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 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"-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

[TonyM]

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

[PMario]

On Friday, June 15, 2018 at 1:28:12 AM UTC+2, TonyM wrote:

Sounding really good, but I hope the "limitations do not restrict our futures"

Which limitations?

 

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.

Ah, OK. ... That's exactly the point with different "roles". ... eg: The "reporter role" is able to assign labels like: discussion, bug, feature-request ... Which makes it easier for developers to "scan" the lists. ... "developer role" is able to create new feature-branches and trigger the automated build process for "prereleases", so everyone can test new functions. ... but only the "master-role" and higher are able to push to master, after the final review process is finished and eg: 2 other developers reviewed and tested the code ...

For documentation it should be much easier to get "developer" and even "master" status. Since it won't break the main core code. ...

have fun!

mario