Move to a Mithril org

[dontwork]

Im just making this issue to see what people, and of course Leo, think. It has come up a couple of times from people in issues and on the gitter channel and it is something I have thought for a while.

I think that the increased professional perception created by moving this repo into an organisation is, alone, enough of a reason to do so but obviously this is Leo's project.

I believe there is a recurring theme at the moment around 'how mithril can be a success' or other things of a similar sentiment and just wanted to gauge what people thought of this simple change which I think could be a move in the right direction

[tivac]

One does exist, but there would definitely need to be some work done.

https://github.com/mithriljs

I'm happy to help however I can with this project.

[dead-claudia]

@lhorie I think it might be a good idea to move this repo to the MithrilJS org. Looks oddly barren ATM, so I feel it could use something.

[orbitbot]

Well, if there is a meaningful discussion to be had, I guess we'd be better off trying to reason about the matter, right? 🙂

Why move to an Org:

• "looks more "professional", so potential corporate adopters might not face that argument"
• might be an opportunity to make use of creative energy from community, perhaps distribute workload, bootstrap a few mithril-related initiatives that have been talked about quite a bit but not acted upon
• could do some lightweight formalising of processes, in conjuncture with above. IMO some ideas are allowed to dry out since there's not an official "seal of approval" by Leo or other people, out of courtesy not tagging something with "official mithril-zalgo-lib" and not even trying to ask other community members for help
• website could live under a meaningful repository name that doesn't cause confusion 😉

Why not move to an Org:

• breaks gitter chat, at least temporarily
• may break a lot of URLs and such, however GH seems to handle its own part fairly well with renamed repositories (at least private ones, dunno about other migrations)
• doesn't really accomplish anything other than a veneer unless some operational changes are done as well, like those alluded to above, and perhaps set out some rules. Mithril redesign #1033 springs to mind, along with a few other bikeshedders'r'us issues
• Leo might not want to? I'm not at all clear on processes insofar that there are any or just routines, but from what I've gathered we're all pretty respectful of Leo's opinions and acts most of the time and I guess he's a BDFL
• also regarding previous, maybe there's not a defined ambition with mithril as a project that would guide . TBH from what I can tell this started as a scratch-my-own-itch project from Leo for his workplace, and maybe that's the extent of what it should be, a viable option in the current breed of frontend JS frameworks rather than something to try to knock candylize, fragmentor or pistontulastic off its pedestal
• most "more professional"-type ideas AFAICT are coming from community members vested in mithril already rather than as feedback from potential adopters, who might be better served with a bullet point list of "why mithril", "why not mithril", "why mithril over" expanded from what's in the current docs
• org might potentially sprout a few more related repos, where the ultimate responsibility could possibly fall to the current admins which probably have enough on their plate
• changes cause organisational overhead which may distract from "normal duties"/"dayjobs"/"family time" etc.

Can someone think of other motivations or concerns, or have some thoughts to share? I personally feel that there are valid reasons for moving, but can also see that it really doesn't have any other impact than a cosmetic change and perhaps would enshrine/reflect reality a bit more since there are multiple core maintainers. Which is probably also a good reason on its own, and incremental improvements are also just fine. I'm assuming some sort of asynchronous distributed goal mapping over GH issues might not really be anyone's idea of a good time, although as a process-oriented person I do see quite a bit of value in the eventual outcome if everything works out...

[dead-claudia]

@orbitbot To cover some of those points, in no particular order:

website could live under a meaningful repository name that doesn't cause confusion

Or maybe, just relocate it to the gh-pages branch of the core repo. If necessary, here's the script I use to deploy my personal site to gh-pages, deploying from dist. The catch with my approach is that I have to keep the generated files checked into source control. The docs can be easily kept in sync like the bundles already are, so that's not a problem. Alternatively, you could use a fixed fork (security hole) of this utility.

breaks gitter chat, at least temporarily

In my personal experience Gitter does redirect, too. (It redirected after me renaming a repo, so I expect it would also redirect migrating to an org.)

doesn't really accomplish anything other than a veneer unless some operational changes

We've already got some areas where we could use some of those changes. In particular, we could totally use a separate discussion repo, where we can have centralized discussion about tooling. That would be much easier to do via a dedicated org. Oh, and it'd make it much easier to address the more opinion-driven issues and ideas from the more opinionated people.

Leo might not want to?

Not sure if he's actually weighed in much, and from the little he's shared about his opinions on the matter, he seems almost as neutral as you could get. Oh, and he's totally a BDFL.

also regarding previous, maybe there's not a defined ambition with mithril [...]

Mithril has never really had much of a roadmap. It's mainly just been a small, mildly opinionated UI framework that's just grown organically. If anything, that's been the primary ambition, a small framework that's highly pragmatic and just gets out of your way of making things.

org might potentially sprout a few more related repos

Or, even better, moving some of the most popular repos (e.g. mithril-node-render) under the umbrella, so it remains logically closer to Mithril itself, even if it's still community-maintained. To cite some precedent, Redux itself is under the reactjs org, despite being community-maintained. So I'm not as concerned. For what it's worth, it's not that hard to only subscribe to some repos within an org, the ones you actually care enough about to interact with.

but can also see that it really doesn't have any other impact than a cosmetic change

It will have a bigger effect than merely cosmetic changes - it's easier to manage things when they're better centralized, and it'll help for the SEO of all under the umbrella.

---

We need to have @lhorie a lot more involved with this discussion, though. So far, his answers have been really inconclusive, and he's the deciding factor on this one.

[orbitbot]

I think that @isiahmeadows replies highlights the issue in many cases, stating that there are motivations to move to an org, but most of the points actually note things that are unrelated to where the repository lives, but rather relate to how things are done.

Ultimately I feel that this is a question of a decision process, in that there's a push from the active community and some of the maintainers to move to an org, whereas the BDFL is undecided or negatively inclined. I too echo @isiahmeadows thought that there would be value in putting more stuff under the mithril umbrella, such as the aforementioned mithril-node-render if @StephanHoyer agrees, from purely discovery reasons if nothing else. With other initiatives, should every good idea be set up in the org, should they prove their merit elsewhere and then be adopted, is it a question of who the initiator is, is there a set process or is stuff decided on a case-to-case basis (does making rules pay off?).

So one model that might be reasonable would be to move to an org, separate the repos into whichever makes sense for administrative purposes (easier tracking of issues and discussions), maybe adopting some outside repos and assigning maintainers (the original owners, presumably). So far to me the total workload hasn't increased, there might be a better separation of concerns.

Additionally this might open the opportunity to assign someone else than the core maintainers some longer-term projects and grant them decision-making power (under review processes) for related projects/initiatives, if that feels meaningful. The main thing that comes to mind for this would perhaps be website tweaks, where there is already some issues opened where IMO the core maintainers could easily delegate to some other person. I'm not volunteering, but originally the design was assigned to someone else, but in the end Leo ended up doing stuff himself anyways (AFAIK). Since we now have a solid base of content and structure to start with, maybe a handoff might be more reasonable now rather than when everything was up in the air.

Since there's a few people who have 👍 the OP, maybe they would like to pitch in as well?

[spacejack]

The org would be a plus for us, it's just one more thing that helps sell-through mithril as a viable framework to certain clients.

[dead-claudia]

@orbitbot You pretty much hit the nail on the head. The main difference in moving to an organization is that the process would change. It has very little to do with where a single repository lives, so much as the process governing the community in general. Node's migration from a collection of various projects to a centralized organization (nodejs)/foundation (Node.js Foundation) is a very well documented example of how moving to a centralized organization with a dedicated process changes things dramatically, when you look beyond the veneer of it being in nodejs/node instead of joyent/node.

It brings a very big sense of maturity to the project, both to those working on the project itself and to those looking in from the outside. Someone unfamiliar would read creationix/nvm as some side project somebody wrote one day and facebook/react as some random project a company decided to open source. But it'd be way easier to see nodejs/node as a truly serious runtime, and mochajs/mocha as a serious test runner. Human psychology is at play here, because the former two are things that seem tied to an individual or company whose main product most definitely isn't that project, and the latter two are clearly branded as not merely a project, but an integral intersection of an entire community that have themselves formed around that project.

And I can tell you that when a project appears mature with a clearly vibrant community, that sells on its own, both to technical and non-technical people.

Since there's a few people who have 👍 the OP, maybe they would like to pitch in as well?

I'm actually one of them. 😉

[dead-claudia]

Closing, since this issue has not been updated in over a month, and typically, issues inactive for that long do not usually produce any action. If you feel something in Mithril needs added or changed, please file a new issue.