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
That's up to the individual user
Nothing stops someone from forking, branching, making one commit, and then filing a PR before pushing the next 12 commits. That's all down to the individual person filing the PR when they decide to do so. We have no idea how many people have local branches of core that they've done skunkwork stuff in and never bothered to share. This is really no different.
That is, Perfectionist Pat and Sloppy Sam are both able to use GitHub, just as they both use the current issue queues. Nothing much changes.
Redesigning drupal.org is
Redesigning drupal.org is already on the Content Working Group's roadmap, but will naturally require coordination with the other working groups to implement.
Following this issue to hear what ideas folks have and in particular what pain points exist with the current site.
Some features are missing
I mentioned this in the issue summary but let me elaborate
So, the way github works, an issue is opened, you decide to work on it, create a branch in your fork, hack on it, PR it back.
This is a Perfectionist Pat workflow. This is a workflow that also works well when you work on a dayjob and you are assigned tickets and you are resolving them.
This is not a community-based workflow, however. If I post a patch to the issue queue, there are a large amount of people who have a chance to see it -- anyone subscribing to that issue, looking at the queue for that component, etc. If I push a commit to my own fork, that's more of a "If a tree falls in a forest and no one is around to hear it, does it make a sound?" kind of problem.
I have emailed github roughly outling a solution where one fork/branch from an issue and the created, related branch will automatically get a PR and that PR is linked from the issue. Now, visibility is back.
However, until the visibility issue is solved I will maintain that this is a hype-induced, not-well thought out idea which will, in one deft move, fragment any collaborative Drupal development beyond any repair.
Effort vs return - use external tools?
I think it'd be a lot of effort to build, it might be better to use e.g. Trello or other PM systems instead?
Could we maybe get this tried
Could we maybe get this tried out in some of the major Drupal distributions, and see if it actually gets a lot of use among site builders ? That might get it enough attention that running the server module on d.o would get support.
Yes please
This would also resolve the disconnect between people who contributed on patches vs worked on the initiative branches, so yes please :)
Some linking is good, but it can be overdone
I think linking to contributions both in core and contrib from user's profiles is good. I think overdoing the "gamification" part is bad, I want people helping and fixing bugs because they know what they are doing and need the fix themselves, not because they are trying to get a higher score.
The Certified To Rock scheme was about as far as I'd take gamification, and even then I'd lean towards making it more open.
However, I don't see the lack of recognition being the primary bottleneck holding us back right now. I think there are bigger problems we might be able to make some headway on.
I support this, but there aren't any appropriate tools
I see the need, but I don't see something we could spend resources on and get a worthy result from. All the PM tools currently in use are just hacked-up issue trackers and gantt chart builders anyway. Project Management of software projects is just not something our industry has made very scientific or rigorized.
Some of the most well-run projects I have worked on used a whiteboard, maybe a couple of google docs spreadsheets, and a few wiki pages to run everything. In general, the more sophisticated the tools, the worse the project was run.
This isn't to say I don't see the pain and feel the need, but I just don't see getting any result back from the investment in this.
Get them in here!
Just because they're not active now doesn't mean they're not welcome. :-) When we started adopting Symfony components one of the key reasons was that Fabien and Lukas came onto g.d.o to help answer questions. It wouldn't be odd for a GitHubber to show up in this thread to answer questions, it would be fantastic. :-)
(Feel free to quote that back to them.)
Yes, let's talk to them
Thanks, Gaelan. Let us know what they say.
It's certainly true that in my experience the GitHub issue/PR categorization/curation tools are weaker than Drupal.org's. However, Drupal is no small project. If we move to GitHub wholesale, we'd likely become the most active PHP project very quickly (eclipsing Symfony, the current PHP leader). That gives us some weight to throw around, and it would be a coup for GitHub for us to move to their platform. We absolutely should try to leverage that to see if we can encourage them to evolve to suit our needs. Ironically, that would probably be easier if we were not using all-free services from them, as it then becomes in GitHub's financial interest to improve in ways we want. :-)
I don't think this needs an initiative
On one hand, I don't think it's a good idea. I'd prefer we improve the current forums. I consider the support content there important, and I don't like trusting important stuff to 3d parties that may go the way of Google Reader or Geocities or whatever. StackExchange is also a little too gamified with all the points and etc.
On the other hand, for the people who prefer Stack Exchange, there is already enough mass effect for those forums to be effective, and as others noted they rank quite highly in google.
I think we would lose something by closing our own forums, and not increase it by much in Stack Exchange.
On the other hand, I do think that people like me who are against this should maybe take it as a signal to do better in our forums.
Very much in favor of this.
Very much in favor of this.
More notifications for issues too
Currently, we don't get a notification if a test passes, so you're required to check back regularly.
.
Ideally I think an arbitrary project like this or or this requires data collection before any decision is made. I suggest adding a dedicated resource to accomplishing the following for either project in the project details:
I don't want to add yet another idea to the voting queue, but I would propose merging both opposing ideas as a "Support Discovery and Implementation 2014" idea.
Personally, I don't participate in stackexchange primarily because I disagree with gamification and closing of threads. I feel that the decisions on the latter are arbitrary and that discourages me from joining. I am in the minority, and I will probably have to deal with it because I should contribute more support and encourage peers I work directly with to use whatever tool is chosen.
If it's done in a way that
If it's done in a way that other organizations can duplicate it, then it's well worth it. A solid Drupal q-a/knowledge base system that can also convert to forum posts or issue queue tickets has applications for anyone who needs to provide a support site.
Stack Exchange is great and all, but how would I deploy it for myself? It's closed source. And I'm not sure they even offer the code to people willing to pay for it.
Plus, I'm not impressed with the quality of Drupal Answers. Both my co-worker and I have asked questions, and not gotten any decent feedback on some of them. Something that integrates with the issue queues is far more likely to draw maintainers eyes, and thus more likely to receive good answers.
GitHub's Response
I emailed GitHub about this, and they said I could post the reply:
To Clarify "/jobs" vs. "/drupal-jobs"
https://groups.drupal.org/drupal-jobs is an actual GROUP whos posting guidelines state "This group is for businesses seeking employees/freelancers to work on Drupal-specific jobs. This is not for people seeking work or for recruiters."
https://groups.drupal.org/jobs is a VIEWS Page-Display listing ALL job nodes across ALL groups.
I took a quick peek at the 1st 4 pages of posts on /drupal-jobs and saw that of the 80 posts, 78 were JOB nodes and 2 were EVENT nodes that related to a job fair or similar event. It's important to note that the EVENT nodes [while job related] would never appear on /jobs.
Just thought I throw out a couple simple facts to keep the conversation well informed. ;-)
~ DougVann [Drupal Trainer, Consultant, Developer]
~ http://dougvann.com
Jobs Section
There's already a Jobs group at https://groups.drupal.org/drupal-jobs. Why should there be more than on Jobs area?
Ken
It might be worth shooting GH
It might be worth shooting GH a email pointing them to this issue; they might be able to say something like:
Or:
I'm not sure if they will care enough to add new features "just for us", because there is no financial incentive for them (unless we find something that we want to be private, maybe Bluecheese).
EDIT: I've gone ahead and done so.
Let's try it out now
Thinking more about this: we don't have to wait until we make a decision as a whole community, we can start to experiment with Github now already as individuals.
Example: I have disabled the issue queue for https://drupal.org/project/drupalpractice and I'm going to develop it exclusively on Github. The only annoying thing is that I have to push my commits to 2 remote repositories now (because I want the dev snapshot on drupal.org). I'm going to write a simple script to auto-sync the repositories with a cronjob on a server.
I'm planning to move over some other Drupal modules too I maintain (only with consent of co-maintainers), then I'll see how well the issue queue works there for me.