Recent comments

Events happening in the community are now at Drupal community events on www.drupal.org.

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:

  1. Review the list of submitted proposals and "vote up" and/or comment on ones that speak to you.
  2. If you don't see your idea reflected, propose your own ideas using the idea template.
  3. While we want to hear about everything that's on your mind, we're especially interested in small, but impactful ideas.
  4. 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!

Recent comments

Gitlab
(in response to Move Git repositories to Github)
Posted by attiks on 2013-08-27 08:57
attiks's picture

I added GitLab to the spreadsheet as well, so we can compare

I started to simulate a d.o
(in response to Move Git repositories to Github)
Posted by Gaelan on 2013-08-27 08:24
Gaelan's picture

I started to simulate a d.o issue (#287292) in github. Will finish tomorrow/later today (it's 1AM). https://github.com/Gaelan/test/issues/1

What you're seeing is the
(in response to Redirect Drupal support forums to Stackexchange Drupal Answers)
Posted by mikl on 2013-08-27 08:19
mikl's picture

What you're seeing is the result of the current consensus on the site. When we make it the official support site, that dynamic will very likely change.

Each Stack Exchange site finds its own balance on how to interpret the rules. It works very well for, say, Ask Ubuntu.

so random passerbys are a no-go
(in response to Move Git repositories to Github)
Posted by Gábor Hojtsy on 2013-08-27 08:19
gábor hojtsy's picture

So random passerbys are absolutely a no-go in terms of issue management. Eg. I cannot go and mark someone else's issue needs tests or even reopen it.

We could have a bot with
(in response to Move Git repositories to Github)
Posted by Gaelan on 2013-08-27 08:08
Gaelan's picture

We could have a bot with commit access that obeyed everybody, but that's an ugly hack.

Access!
(in response to Move Git repositories to Github)
Posted by Gaelan on 2013-08-27 08:07
Gaelan's picture

Here is how the access works (yes = can edit, no = can not)

Attribute Committer Creator
Title/Body Yes Yes
Open/Closed Yes Yes
Tags Yes No
Milestone Yes No
Assigned Yes No

update status, localize.drupal.org
(in response to Move Git repositories to Github)
Posted by Gábor Hojtsy on 2013-08-27 07:47
gábor hojtsy's picture

Update status can already handle projects from different sources (eg. feature servers outside of drupal.org), the only requirement is that the update summary data is available in the expected format on that server.

The localization server (module powering Localize.drupal.org) can also be used on independent servers set up to translate whatever projects. There is a per project download URL for translations in l10n_update module (and built into Drupal 8 core), so you can get projects from different sources and still get translations supplied, again so long as the provided information on the 3rd party server is in the expected format.

I don't know about simplytest.me or drush pm-*.

crowdsourced issue management
(in response to Move Git repositories to Github)
Posted by Gábor Hojtsy on 2013-08-27 07:44
gábor hojtsy's picture

Currently issue management is crowdsourced. Anybody can tag an issue "Needs work" or mark it for backport, or figure out it needs an upgrade path. These are currently expressed with statuses and tags. If only maintainers can do these things, then issue triage as a thing will not be able to exist anymore and the crowdsourcing of issue management to initiative teams, etc. will not work...

What about all the contrib
(in response to Move Git repositories to Github)
Posted by joachim on 2013-08-27 07:15
joachim's picture

What about all the contrib maintainers?

Also, if only committed can edit tags, how can a user reopen an issue? Or mark it 'works as designed' when they realize they've made a mistake?

This puts more work on maintainers.

I used Phabricator,
(in response to Implement select Phabricator components on Drupal.org)
Posted by Wim Leers on 2013-08-27 07:06
wim leers's picture

I used Phabricator, Differential and Arcanist while I was at Facebook. It was a great toolchain. Much better than what we currently have on Drupal.org.

I could say more, but it's now been >1.5 year since I've used it, so I can't speak about the current state of things.

P.S.: I still have fond memories of Pokémon and memes appearing when posting a code review containing "lgtm" or "shipit" or whatnot :)

We should add GitLab to this.
(in response to Move Git repositories to Github)
Posted by Gaelan on 2013-08-27 07:01
Gaelan's picture

We should add GitLab to this.

No, but only committers can
(in response to Move Git repositories to Github)
Posted by Gaelan on 2013-08-27 06:48
Gaelan's picture

No, but only committers can edit the tags, and I think we can trust Dries not to make a patch "closed (fixed)" and "closed (won't fix)" at the same time. :)

Status and component are
(in response to Move Git repositories to Github)
Posted by joachim on 2013-08-27 06:39
joachim's picture

Status and component are orthogonal. Mixing them up in a single vocabulary seems messy to me.

Can we enforce a single component? A single status?

The tags are generic; they
(in response to Move Git repositories to Github)
Posted by Gaelan on 2013-08-27 06:31
Gaelan's picture

The tags are generic; they can be used for anything. The defaults include both status and category. You could easily add more tags to represent components.

-> i believe the maintainer
(in response to Move Git repositories to Github)
Posted by joachim on 2013-08-27 06:20
joachim's picture

-> i believe the maintainer would ask close the core issue and ask to create the issue within the contrib module

So that's quite a big regression from our current workflow, where the issue can just be moved to a different project.

-> the github issue queue allows to tag issues. by default, the following tags are provided:
bug, duplicate, enhancement, invalid, question, wontfix
the available tags can be customized by the project maintainer(s).

That's issue status. Do GH issue have a concept of components?

Mail From Github
(in response to Move Git repositories to Github)
Posted by Gaelan on 2013-08-27 06:09
Gaelan's picture

Mail from GitHub:

Gaelan,

I haven't heard of anyone doing quite what you say here [referring to my "Druplicon sees the world" idea], but something that definitely does happen all the time are pull requests from fork to fork. So rather than just editing someone else's pull, you just make a pull request from your fork to their branch. Unfortunately, it requires a little more know-how to target a network branch than to just update a d.org issue as they are today, but this is absolutely something people do.

Something else to consider, and what I'd probably suggest, is that you can make a pull request from a branch to master in the same repository. Many, many open-source projects work this way. The core maintainers work on branches in the main repository day-to-day, and occasional or drive-by contributions are handled with forks.

With this setup, you get all of the same pull request goodness without any of the fork friction. The only thing that would be a real change from d.org's current workflow is that it would be harder for a core contrib to jump in and fix a new contributor's pull request without something like what you've said. The usual core contributors could all edit each other's branches as they can now.

People do run into this, and what usually happens is that the core contributor will check out the pull request, fix it up, and push to a branch on the core repo and merge that.

Your idea of an API that grants permission is possible. It's easy to imagine an oauth application that contributors give access to which will grant core contributors permissions on repositories named `drupal-*` or something. I'm not sure we'd exactly *recommend* it but people integrate with project management systems in lots of ways.

Hope this helps,
Ben

I think the linkrot point is
(in response to Move Git repositories to Github)
Posted by webchick on 2013-08-27 06:05
webchick's picture

I think the linkrot point is a fair one, but OTOH I will also say that due to the lack of easy image inlining (which Github has), I used to use Skitch extensively before it became a flaming POS. So just because you can upload a file doesn't mean people do if there's an easier way around it.

The spreadsheet appears to
(in response to Move Git repositories to Github)
Posted by Gaelan on 2013-08-27 05:10
Gaelan's picture

The spreadsheet appears to have been spammed. We should revert it.

I love Drupal and I love open
(in response to New, redesigned drupal.org theme)
Posted by halstead on 2013-08-27 04:10
halstead's picture

I love Drupal and I love open source. I find the closed nature of Bluecheese problematic and disheartening. I'd love a new design and I hope that any redesign can reflect our core, open source, values.

Also mobile first. ;)

We've seen in the past that
(in response to Move Git repositories to Github)
Posted by greggles on 2013-08-27 02:53
greggles's picture

We've seen in the past that 3rd party services tend toward linkrot (e.g. skitch-hosted files uploaded to the issue queue from years ago are now missing) while we've kept attachments on our sites alive and well.

I don't think we can or should dismiss this feature so quickly.

Subscribe with RSS Syndicate content

Recent comments

Group organizers

Group categories

Difficulty to implement

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: