Recent comments

https://www.drupal.org/drupalorg/blog/developer-tools-initiative-part-5-...

There are other areas that need change, I did a summary and proposal in this post:

https://steemit.com/drupal/@develcuy/is-drupal-the-right-tool-for-drupal...

Feedback is welcome!

I think this sounds like a great idea.

Like this idea.

You'll find that many of the most popular Wordpress commercial themes all have "drag-and-drop" template builders. Sometimes for devs it might be a lot more tedious having to deal with someone elses design builder, but it definitely appeals to a much wider audience.

Just like you said, non-coders approach it.

Please look at the title of this group. 2014. Please read the specific comments I linked before:

the one by jthorson from May: https://groups.drupal.org/node/313068#comment-1037488 and webchick from August of 2013: https://groups.drupal.org/node/313068#comment-955593

I've been thinking about how to get the best of both Github and Drupal.org.

The approach that would make most sense to me, is this :

1. People host their project on Github.
2. People register their Github repository on Drupal.org as a "theme", a "module", etc.
3. The Drupal community leaders can add flags to these projects to make them "official", "recommended", "deprecated" or whatever.
4. Drupal.org polls for changes to these projects, triggering new review workflows when changes are detected.

That way, you truly get the best of both worlds. You get :

1. Drupal.org as a centralized, curated, end-user-oriented system that allows you to easily search for modules or themes, and
2. Github as a decentralized, developer-oriented system for easily maintaining and improving own open source projects.

jQuery plugins are managed this way.

The best of both worlds can easily accomplished using gitlab, and allows Drupal_infra full control over the service.

A typical way to deal with issues on Github :

1. User X finds a bug.
2. User X posts a description of his error on the issue tracker
3. If the issue is indeed a bug that needs to be fixed, core developer Y is assigned to fix this issue
4. Developer Y updates his own repository and fixes the bug.
5. Developer Y merges his changes with the main repository.

Another typical way to deal with issues on Github :

1. User X finds a bug.
2. User X does some debugging and finds the bug in the source code
3. User X updates creates his own repository and fixes the bug.
4. User X sends a pull request to have his his changes merged with the main repository.
5. Developer Y approves the changes and merges them with the main repository.

At any time, the repositories of user X or developer Y can be cloned by a third user who wants to continue their work. Multiple users can collaborate on a single branch of a project without interfering with the main branch. Milestones and labels can be used to organize issues. etc.

Git is extremely flexible, and you can set it up in many different ways. However people have very strong opinions on what are good conventions to adhere to in using git. However it is setup requires some coördination, but certain ways can require more or less. The general term to search for is "git workflow" to find discussions about this.

Note that every git checkout is a repository, so in some trivial sense every developer must indeed have their own repository. It is quite possible to only have one "shared" repository on github, either with multiple keys, or one key. This requires more coördination up front -- you have to agree on where the development is headed. With multiple "public" repositories, you can delay this. People can look at each other's work and discuss whether it should get merged into a blessed repository.

(You can also do this with multiple branches on one repository, and you can also do discussions via sending around patch sets, it's just matter of what's easier.)

source

There are two main workflows. Both assume each developer has set up a github account which is free and sensible:

1. Add other developers as collaborators to your main repository so they can push their changes to it.
2. Let other developers fork your repository and issue pull requests to integrate changes

Collaborators are preferable if a group of you are making or maintaining a software product. There is one repository for the project on github and each developer will have a local repository for their development work.

The forking is useful if there are other teams or developers using their own version of your product. It gives them a way (pull requests) to offer their changes back to enhance your product. Each fork is generally considered as a distinct viable variant of your project.

Forking is also be useful in an open source environment while you are 'coming to trust' a potential collaborator. If you find yourself routinely accepting their pull requests, you may 'promote' them to being a collaborator.

Branches are important and very useful. Its hard to do without them on the remote repo if more than one developer needs to work together on an experimental feature or significant extension to your project.

source

Git was designed to be used with a repository for each developer. Make an account for each person, then designate one as the maintainer of the master branch. Everyone else will fork the master, and they can work on whatever they want on their own. Once they finish something they will send you a pull request and you can pull their changes into the master branch. Then everyone else can pull from the master as often as they like (once per day, twice per day, etc).
Managing multiple branches may sound difficult, but as long as you communicate effectively it shouldn't be an issue. Once a developer finishes a feature it's important that they send you a pull request and they don't just sit on the commits and nobody knows about them.

A possible good policy for developers to follow before sending a merge request is to have them pull from master and ensure that there are no conflicts.

If you really want to use one account, you don't have to share the same key. Github allows you to upload as many keys as you want. However, if you want something that works like SVN you should use SVN because Git isn't designed to follow the same workflow as SVN.

source

Further reading :

• Forking, Fetching, Pushing, Pulling
• How to GitHub: Fork, Branch, Track, Squash and Pull Request
• Git workflow: Forks, remotes, and pull requests
• Effective pull requests and other good practices for teams using github
• Team Development with Github
• Comparing Workflows
• ...

"Can you expand on what elements of being on github would make it easier?"

For me, what I like most about Github, is the fact that I can easily (1) fork a repo, (2) make some changes locally, (3) update my repo and (4) send a pull request to update that repo, all just by pushing buttons in a browser or simple UI tool, without even having to write ANY command line code.

Also, most developers already know how to use Github, making it a much smaller step for people new to Drupal to contribute to if it's on Github. In my experience, Github is also better documented, their procedures are simpler to understand, their automated testing tools are pretty awesome, etc. There's so many reasons to move to Github, really, that I really don't get why you haven't already.

It seems to me the Drupal community is somewhat stuck in the days of yore and needs to evolve faster if Drupal isn't to become replaced by something newer, bolder and more shiny in a not too distant future.