Welcome
Welcome to the brainstorming group for the 2014 Drupal.org roadmap! This group is to help the Drupal.org Software Working Group gather community input into the 2014 budget and plans for Drupal.org improvements. Please read the announcement for more background/details.
Latest ideas Most popular Recent Comments
To participate:
- Review the list of submitted proposals and "vote up" and/or comment on ones that speak to you.
- If you don't see your idea reflected, propose your own ideas using the idea template.
- While we want to hear about everything that's on your mind, we're especially interested in small, but impactful ideas.
- Proposals are wiki pages, so feel free to provide additional details in other peoples' proposals; think of them as "issue summaries" for ideas, so keep them neutral.
Voting/feedback will considered until 00:00 GMT on September 6, 2013, in order to give us ample time to make a proposal (which the results here will be a part of) for the Drupal Association Board Retreat prior to DrupalCon Prague. Thanks for participating!
Subscribe with RSS 
Recent comments
Out of the box
Out of the box, no, but since it is open source we can easily use the API (or custom code) to create a fork and give everybody (or everybody in that issue) access to it, or his/her own branch.
We can setup the 8.0.x branch to track Drupal and only allow merge requests to it, so once the issue is finished we have a clean patch.
AFAIK this is a just technical problem that can be solved
The question that kills github
The current drupal.org workflow is such that if A posts a patch then B can post the next patch. This is simply impossible with github unless A gives permission to his/her repo to B which of course is not viable. Does gitlab allow for such "swarming"?
One of the great problems
One of the great problems that i see in the forums is that people do not use the search feature or read the documentation. The reason must be diverse for each of the users. I could possibly try some psychological argumentation, but i believe that it would resolve little or nothing.
Creating an interactive help form (in truth a disguised search) and in a highlighted position might be a path. The results would of course be 'user friendly' (this part deserve more though).
One way of helping the search engine could be to give the capacity to the users to categorize (tags) the post in the forum. Then for example, when i submit my logging problem, the posts with more 'logging problem' tags could appear first. The solved problem could also have a factor to prioritize them in the results. Many different factors could be implemented to help the filtering and aggregation of the posts.
Different results could be given: forum, issues or documentation...
Edit: made some additions and corrections.
gamifying the forum
My personal feeling is that reproducing Stack Exchange would be unproductive. They have their system and it is working (with positive and negative effects). Drupal.org shouldn't loose sight of its focus. Which is, i think, to develop drupal and its community.
To gamifying the forum would cut it loose of the spirit of free sharing. Stack Exchange exist only for itself in that sense, although a strong will and presence can achieve great things as it is the case.
One alternative would be to simply analyse the real defaults of the actual system and find specific solutions to them, prioritizing the more pressing issues. In so doing, little by little, an integrated and global solution should appear by itself. Let the help system grow, like the module ecosystem and even the different version of drupal have done.
+1 for github
lock it.
@orlissenberg - please read the whole thread
@orlissenberg - please read the entire thread of comments if you want to meaningfully add to the discussion. This is not a simple issue, and it doesn't seem like you've read e.g. 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
we should probably lock the thread at this point?
Can you expand on what
Can you expand on what elements of being on github would make it easier?
There's a lot of pros and cons to consider. Knowing the specifics and why they matter to people will help to evaluate them.
+1 for github
It would greatly lower the bar for me (and others) to contribute.
Better tools via Github
Other than the issue queue, the tools available on Drupal.org are subpar in my opinion. Managing a project on Drupal.org still requires a lot of manual work that should be automated. The most glaring example is patch testing.
On Drupal.org, if one has a module that integrates Drupal with some third-party code or application, there is no way to functionally test that other than download the patch, apply the patch, test locally, report back. That becomes extremely inefficient extremely quickly.
Using a real CI tool like Travis, the tests for that module can build and configure an appropriate environment, run tests on a pull request, and report back whether or not it's good to merge. Additionally, you can use a tool like Coveralls to record code coverage on those tests.
For me at least, it's a much better developer experience on Github. There's merit in trying to only eat what you cook yourself, but at some point the cost/benefit weighs more in favor of leveraging third-party products.
just one comparison. Code
just one comparison. Code reviews and merges in Symfony take days, sometimes just hours (seriously). I've seen contributions taking months (of course each case is different).
So, tools is the key. Being able to review while you are commuting or while you are in your mobile/tablet is great, and that's just some of the advantages which we are missing sticking into an old fashioned solution.
Drupal GitLab module
Here's the API module. It's not 100% API complete just yet but it works (we use it for Dropfort.com)
https://www.drupal.org/project/gitlab
It doesn't do anything on it's own, just if you want to play with the API.
We didn't use the PHP library mentioned in the API docs for GitLab since we wanted to build it in a "Drupaly" way. We wanted to make it possible to link GitLab data to fields or entities or just use the webhooks. Hence the dependency on WSData.
WSData (https://drupal.org/project/wsdata) and RESTClient (https://drupal.org/project/restclient) which both take care of caching, the actual HTTP requests, adds the ability to link data to entities and other configuration.
Anyways, if anyone has questions on how to use it or want a demo, just post to the issue queue. We haven't gotten any example code published yet but when we do I'll update here and on the module's project page.
Thanks.
We have other modules to
We have other modules to publish as well. Just haven't gotten to it.
I'll see about getting those up for next week.
Looking at
Looking at https://drupal.org/project/gitlab_webhooks it would appear that @minorOffense is still working on something.
Big fan of GitLab as well and I feel it would be preferable to direct migration efforts towards another major open source platform, rather than go with a proprietary Git solution.
Even if few d.o contributors would venture into the Ruby codebase (not sure the language is the main issue anyway - how many people contribute to d.o tools now?), the scale and exposure of d.o alone would probably help improve GitLab.
Where did this end up?
I think gitlab would be a great solution, has this gone anywhere?
Edit: This is also something I would be very interested in working on.
Just a matter of focus
Github business is to provide a friendly environment for new and diehard coders. Besides that we could have all the issue queue and workflow ensured by consuming the github api.
Github workflow (PRs) is the standard in the vast majority of Open-Source, this also would make things easier for newcomers. Also there is a community and company effort to help people with git, versioning and the workflow of contributing if we move to github.
I think we should invest in the core functionality of D.O, which is not code but people engagement, let it to someone who's core business is to make code easier.
If you want your diff with
Yes that does also seem helpful, and when it would be baked in d.org it would be even better ;)
Yes I noticed that when writing, that's what I meant with ' and is not really promoted on the website/module pages..')
Not sure why I missed it before, perhaps the terminology, but it doesn't really invite the user to just browse the code a bit, compared with Github. But that's probably because Drupal module pages are targeted at people who just implement it first, and developers secondly (while Github is almost only developers).
Perhaps most of it is just a UI/UX issue that could be helped with a layout update, or just shift the focus a bit more to 'new developer friendly' instead of focussed on die-hard drupal developers.
Or do you disagree that the Github user-interface is more user-friendly?
Surely a patch diff and a
Surely a patch diff and a commit diff and a pr diff are all exactly identical -- they are all diffs!!!
If you want your diff with fancy highlighting, you can get that right now on d.org: use https://dreditor.org/. Granted, that should probably be highlighted more and maybe even baked into d.org rather than a separate download.
I understand that every large
I understand that every large project has a lot of 'half-done' stuff, but the problem was more that it's hard to see what actually changed in a quick overview, when I compare a .patch attachment vs a commit/pr code-diff in github.
A quick way to see the result of the changed files (or entire repo) would be helpful indeed.
The issue tracker is often
I am sure big github projects are full of half-done branches too! That's just the nature of work on big projects, particularly when many people are volunteering their time.
It would be pretty easy to have d.org provide a tarball download of the module with a particular patch applied.
As I'm writing this, I just
That is linked to from every project page -- look at 'repository viewer'.
As someone who has been using d.org issue queues for years, as both a user and a maintainer, I find the github issue queues very crude indeed compared to what we have.
Using freeform tags is a terrible idea. We have a hard enough time here when we do use tags for things (eg 'needs backport', 'UX improvements') in ensuring that they stay consistent and are properly used. We have structured data for our issues because that actually works.