{"action":"created","issue":{"url":"https://api.github.com/repos/QQuick/Transcrypt/issues/193","repository_url":"https://api.github.com/repos/QQuick/Transcrypt","labels_url":"https://api.github.com/repos/QQuick/Transcrypt/issues/193/labels{/name}","comments_url":"https://api.github.com/repos/QQuick/Transcrypt/issues/193/comments","events_url":"https://api.github.com/repos/QQuick/Transcrypt/issues/193/events","html_url":"https://github.com/QQuick/Transcrypt/issues/193","id":190485605,"number":193,"title":"T-RFC1: Cooperation and division of labour.","user":{"login":"JdeH","id":1730289,"avatar_url":"https://avatars.githubusercontent.com/u/1730289?v=3","gravatar_id":"","url":"https://api.github.com/users/JdeH","html_url":"https://github.com/JdeH","followers_url":"https://api.github.com/users/JdeH/followers","following_url":"https://api.github.com/users/JdeH/following{/other_user}","gists_url":"https://api.github.com/users/JdeH/gists{/gist_id}","starred_url":"https://api.github.com/users/JdeH/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JdeH/subscriptions","organizations_url":"https://api.github.com/users/JdeH/orgs","repos_url":"https://api.github.com/users/JdeH/repos","events_url":"https://api.github.com/users/JdeH/events{/privacy}","received_events_url":"https://api.github.com/users/JdeH/received_events","type":"User","site_admin":false},"labels":[{"id":451934994,"url":"https://api.github.com/repos/QQuick/Transcrypt/labels/announcement","name":"announcement","color":"ffff00","default":false},{"id":434074253,"url":"https://api.github.com/repos/QQuick/Transcrypt/labels/feedback%20wanted","name":"feedback wanted","color":"fbca04","default":false},{"id":434168934,"url":"https://api.github.com/repos/QQuick/Transcrypt/labels/procedural","name":"procedural","color":"9999ff","default":false},{"id":484737611,"url":"https://api.github.com/repos/QQuick/Transcrypt/labels/T-RFC","name":"T-RFC","color":"000000","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-11-19T08:57:21Z","updated_at":"2016-11-19T16:58:59Z","closed_at":null,"body":"Transcrypt: the transition from chapel to bazaar\r\n------------------------------------------------\r\n\r\nNow that more people are getting involved in developing Transcrypt, I'm looking for a way to allow this project to grow orderly without myself being a bottleneck. This means that I'll have to let go without losing control.\r\n\r\nWhat I would like to do is to take some parts of Transcrypt, I'll name them subjects, and assign them to  an owner. Any changes to a particular subject go through the owner for approval before being commited. The owner takes responsibility for the code quality of that subject, and it is upto him/her to decide if an when to refactor. I'll stay in the loop as far as code functionality is concerned, and I'll also do the final merges for now, but I will not impose my ideas on code structure upon every part of Transcrypt.\r\n\r\nOwnership: coordinated freedom\r\n------------------------------\r\n\r\nWhen I work on a piece of code alone, it's structure is like a sawtooth. When adding a new feature, I primarily try to get it to work, structuring my code as well as I can, but sometimes postponing reorganization. Until I discover that the sub-optimal structure starts to interfere with my productivity. I then stop adding features and concentrate on refactoring for a while.\r\n\r\nBut suppose my code is currently in flux, not yet being refactored, and someone else starts adding features in the \"messy\" stage my code is in, then I'm in for trouble. This is because this other person doesn't know what orderly, consequent structure I had in mind. He just thinks the current structure is how I wanted it and starts out from there. Because he doesn't have the eventual structure in mind, it will be harder for me to refactor, after he added his features. So what I would do in that case is consult with him, either explaining what the structure will be, or asking him to wait a little until I've made it shipshape again. In other words I assume a coordinating role for that piece of code, I \"own\" it. \r\n\r\nSmallest common multiple rather than largest common denominator\r\n---------------------------------------------------------------\r\n\r\nI believe that in a good development team, people should be empowered to use their specific talents and hard fought skills, including their individual design and coding style, which makes up a great part of the added value of a good developer. I've worked a lot in companies where the lowest common denominator was the norm. Don't want to do that here, it kills the fun and wastes talent. Still for a certain coherent subject, thinly interfaced with the rest, there must probably be one style. But it is the style favored by the owner of that subject, not by me. This holds for interesting parts like overall structure, uses of classes, inheritance, parameters or members, patterns etc., but also for the superficial, often religious ones, like code layout and naming conventions.\r\n\r\nSaying all this I am well aware that any contribution to this project is and will remain on a volunteer basis. Nevertheless I sense that working on an open source project sparks commitment and enthusiasm. The quality of the contributed code I've seen, often surpasses what I get when working with fixed, professional development team. To streamline development of Transcrypt, some permanent, lightweight organisational structure is needed. People assuming certain roles may change, but the roles themselves should be well thought through. And of course, people staying in certain role for a longer time have a positive influence on unity of concept and productivity.\r\n\r\nSo with this T-RFC, I'd like to introduce the notions of 'subject' and 'subject owner'\r\n-------------------------------------------------------------------------------------------\r\n\r\nA subject within Transcrypt is a piece of functionality or activity that is internally highly interconnected, but has a thin interface to other subjects. While this is what programmers call a module, this term is deliberately avoided, since in the Python world it has a very specific meaning. Also a subject doesn't need to concern source code. Probably the concept is made most clear by example. Subjects are e.g.:\r\n\r\n- The Transcrypt core (`__main__.py, compiler.py, __core__.js, __builtins__.js, __standard__.py, __base.py__, ...`)\r\n- The continuous integration system\r\n- The autotest system\r\n- A certain library or group of libraries\r\n- External communications, e.g. the website\r\n- The development process (what I am trying to streamline a bit rightnow)\r\n- Planning and managing of releases\r\n- Commit / merge / branch management\r\n- The demo's\r\n- Tutorials\r\n- ...\r\n\r\nQQuick and invitations\r\n----------------------\r\n\r\nTo fit the GitHub way of doing things, a distinction is made between an organisation and a project. The organization that 'hosts' the Transcrypt project is QQuick. It's aim is to produce open source software. Anything produced by the QQuick organization is open source distributed under a liberal license like Apache 2, MIT or the legacy QQuick license. Since QQuick is still small, I'll make no attempt to invite owners for each and every subject related to Transcrypt. But if someone clearly seems the most knowledgeable about certain part, chances are that he/she will receive an invitation. QQuick isn't yet a legal entity. But it could become one in the long run, probably a foundation. It will never have the aim of making a profit. The current website of QQuick is a legacy thing, which doesn't matter much, since the website of Transcrypt is more important.\r\n\r\n\r\n\r\nLet me be clear: An invitation is just an invitation. There isn't any pressure to accept! If you just contribute code, bug reports or idea's: great, keep up this essential work! But if you feel it would indeed be best for the project if you would own a certain subject, then accept the invitation. Ownership does **not** mean you'll have to code everything (or anything) yourself. If you accept it, issue's and PR's about that subject will be routed via you. Overall functionality still goes through me, and I'll keep a final say in what gets in and what not. But I'll rely on the subject owners to a large extent. Currently I invite myself to be owner of the Transcrypt core. And I've decided to accept.\r\n\r\nJacques de Hooge\r\n"},"comment":{"url":"https://api.github.com/repos/QQuick/Transcrypt/issues/comments/261725318","html_url":"https://github.com/QQuick/Transcrypt/issues/193#issuecomment-261725318","issue_url":"https://api.github.com/repos/QQuick/Transcrypt/issues/193","id":261725318,"user":{"login":"AXGKl","id":9989548,"avatar_url":"https://avatars.githubusercontent.com/u/9989548?v=3","gravatar_id":"","url":"https://api.github.com/users/AXGKl","html_url":"https://github.com/AXGKl","followers_url":"https://api.github.com/users/AXGKl/followers","following_url":"https://api.github.com/users/AXGKl/following{/other_user}","gists_url":"https://api.github.com/users/AXGKl/gists{/gist_id}","starred_url":"https://api.github.com/users/AXGKl/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/AXGKl/subscriptions","organizations_url":"https://api.github.com/users/AXGKl/orgs","repos_url":"https://api.github.com/users/AXGKl/repos","events_url":"https://api.github.com/users/AXGKl/events{/privacy}","received_events_url":"https://api.github.com/users/AXGKl/received_events","type":"User","site_admin":false},"created_at":"2016-11-19T16:58:59Z","updated_at":"2016-11-19T16:58:59Z","body":"Hi, Jacques, good idea to assign owners of certain subjects. \r\n\r\nI did not fully understand what you expect from e.g. me regarding CI when I accept ownership for CI: Am I exepected to follow all issues all the time then? Or would you send me an email with \"Pls ack this and that\" ? Because staying up to date and read ALL transcrypt issues ALL the time I can't guarantee at least not forever, as much as I would like to, its not realistic.\r\n\r\n=> question: maybe its a good idea to split Transcrypt then into different repos where you can then freely assign push perms to certain people you deem capable enough to not screw the whole thing, i.e. owners but also others.\r\n\r\nI would see (first shot, not too much thinking):\r\n\r\n- transcrypt_core\r\n- transcrypt_documentation\r\n- transcrypt_testing\r\n- transcrypt_continuous_integration\r\n- transcrypt_modules [ time, re, logging, ...]\r\n- transcrypt_backend {nothing yet there}\r\n- transcrypt_assets (like demos but also maybe webapps \r\n\r\nI mean then the owner could directly push and also assign push perms to others, core always only you, here only way to get code in is via a concrete PR (or a request to you). The core than just has refs to certain version of those subrepos.  (I just know how this works in mercurial but I think in git its also possible to include subrepos in the main one, keep the version fixed until a PR for it come from the owner or an authorized delegate).\r\n\r\n\r\nThen you don't have to follow each and every discussion regarding sub repos and just can relax and await the final conclusion in the form of a PR for a git subrepo version change within transcrypt_core\r\nAlso as an owner of e.g. CI, with full perms on that I could directly give also full perms to e.g. @RCL-Carl, to speed up agility on such a non critical subrepo. "}}
{"actor":{"display_login":"AXGKl"}}