This is a template issue. You can use Dreditor to clone this issue to create a new project-specific issue.

n.b. This will not be an issue for the project's own issue queue (you may already have one of those), but rather for this "Drupal 8 Contrib Porting Tracker" project's issue queue.

Please search first and make sure the project-specific issue doesn't exist.

Then, delete this text, delete the bogus "Parent issue" below the "Issue summary", and start filling out your stuff!

If some sections aren't applicable to the project or are unknown, please leave the section and put "N/A", "Unknown", "None", etc.

You will need to refer to our project page to learn which value you should use for your issue's status (along with other information and answers to FAQs).

# Summary

(A sentence or two describing what this module does and why it's needed as well as a sentence on current porting status, if known.)

# Project URL

https://www.drupal.org/project/XXXX

# Where is the code?

(A link to where to find the code. If a patch is available on drupal.org, add a link to that issue.)

# Estimated completion date

(If known, when is this module targeted for completion?)

# Dependencies

(What other modules does this one depend on? Ideally, link to the dependent project issue if it already exists.)

# Who's doing the port?

(People actively working on this, companies funding the effort, etc.)

# What help do they need?

(Are there specific types of resources (e.g. skillsets, $, sprints) that would be helpful to expedite porting?)

# D8 roadmap

(A link to a meta issue, handbook page, Google Doc, etc. with the plan on how to port to D8.)

# Background and reference information

(Links to any other helpful information, documentation, etc.)

Members fund testing for the Drupal project. Drupal Association Learn more

Comments

webchick created an issue. See original summary.

webchick’s picture

Issue summary: View changes
webchick’s picture

Issue summary: View changes
webchick’s picture

Version: 8.x-1.x-dev » 8.x-0.x-dev
webchick’s picture

Issue summary: View changes
webchick’s picture

Issue summary: View changes
webchick’s picture

Issue summary: View changes
webchick’s picture

Issue summary: View changes
Kristen Pol’s picture

Issue summary: View changes
Kristen Pol’s picture

Issue summary: View changes
Kristen Pol’s picture

Issue summary: View changes
Kristen Pol’s picture

Kristen Pol’s picture

Issue summary: View changes
webchick’s picture

Thanks for the edits. Based on that I think we might want to change "Git repository or patch" to "Where is the code?" to cover all cases.

We might also want to make a separate "D8 tracking issue" field, though not sure. This is handy while the module is being ported somewhere else, but hopefully as quickly as possible a module's going to move to Drupal.org in the 8.x branch, and then often these issues go away in favour of using separate issues against the given branch. So I think "Where is the code?" could cover that.

Kristen Pol’s picture

Issue summary: View changes
Kristen Pol’s picture

Just seeing #14. Yes, I like "Where is the code?". I was also thinking about a separate section for the D8 issue but agree that it can be covered by "Where is the code?". I'll update it now and on the couple existing issues.

Kristen Pol’s picture

Issue summary: View changes
webchick’s picture

Title: [Template] Module Name » [module_short_name] Module Human-Readable Name

Another thing that came up from talking to DA staff... it would help them a lot if the titles of these issues contained the module shortname, because this way they can place a box on all project pages without a 8.x stable release that points over to its issue here (yay!). This will help with human searching as well.

Updating the template with the suggested format from Jakob et al, and I'll go update the other tickets now.

webchick’s picture

Title: [module_short_name] Module Human-Readable Name » [module_short_name] Module Human-Readable Name (Issue Template)
pedrorocha’s picture

I think it would be good to have a section "Where to give feedback?", as many modules migrated the development to Github and this can causes some communication problems with people reporting on the wrong place and waiting for too long without the developer who is porting actually knows about it.

webchick’s picture

Honestly, I think that ship has already sailed for many of these modules. GitHub has a better developer experience, lower barrier to entry since developers are already there, and most times when this is happening it's because the people doing the porting don't have maintainership access to push their code to D.o themselves.

At the end of the day, the goal is not to force developers doing the actual work on porting these modules to use tools they don't want to use in order to contribute back. The goal is instead to get visibility on Drupal.org that stuff around these modules is happening, and to incentivize those developers, regardless of where they're porting stuff, to push record of their work back on Drupal.org project pages. (Working with the DA to get an info banner on the project pages that points over to this queue.)

If you want to discuss the meta topic of tool use and its impact on the overall community, probably the Technical Working Group queue would be the best place to do it.

Kazanir’s picture

If someone knows that the developer is using the Github issue queue I think they could just link that in the notes or the roadmap sections and that'll be enough.

webchick’s picture

Yep, that works.

pedrorocha’s picture

Yes. I was just saying that, not to change the tool or anything like that ;)
It was because I wanted to report an issue on Pathauto and didn't know where it would be better(reported on D.O in the end).

webchick’s picture

Priority: Normal » Critical

Moving this up in the list.

webchick’s picture

And oh, I see what you mean. "Where to post feedback" as a separate field, and it could point to D.o or GitHub.

Honestly, for that, I think we should default to D.o, always. The few exceptions would be if the project page explicitly says "We use GitHub for issues" (e.g. Drush), but then we could just say that under the "Where to find the code" section I think.

mglaman’s picture

Proposing update to template:

<h3 id="kanban"><a href="#kanban">#</a> Kanban board</h3>
https://contribkanban.com/board/MACHINE_NAME/8.x-VERSION.x

ContribKanban.com will automatically create boards for projects if they are viewed but not present in the database. Takes a second to reload, but still automated.

webchick’s picture

So... not sure about that. (Sorry, when I answered you in Twitter I thought you meant adding a button or something to link to a module's contrib kanban from the contrib_tracker contribkanban.com's tickets.)

I think it's great to link the kanban (probably under the "D8 roadmap" section) if they are actively using it, such as the Media team... but if not, it starts to kind of look like advertising. Not sure.

mglaman’s picture

That's true. I'll just leave it then that if that project is using it they can copy that HTML and paste it, then.

webchick’s picture

Priority: Critical » Minor

I've noticed that when people clone this issue it makes everything critical by default. I chose critical for this cos I wanted it to stand out, but let's try standing out on the opposite end instead.

Kristen Pol’s picture

Issue summary: View changes
FluxSauce’s picture

Issue summary: View changes
FileSize
49.35 KB

Not sure if this is the right place to report this, but I've got a rather nasty message on https://www.drupal.org/project/site_audit about how there isn't a Drupal 8 port, when there is actually a full Drupal 8 port.

False Positive

How should I proceed? Thanks!

loopduplicate’s picture

Hi FluxSauce,

That message does look nasty. I don't know much about that so maybe someone else can chime in. But, I'm going to create a ticket for the contrib tracker for Site Audit so that, I guess, will get rid of the message.

Regards,
Jeff

loopduplicate’s picture

Hi FluxSauce,

Here's what I created so people will know your module is ready when they are searching through the contrib tracker:

https://www.drupal.org/node/2606726

Regards,
Jeff

jweowu’s picture

Could the person responsible for making this warning message appear (and telling people to look here) please update this issue's description with details of exactly what the criteria is for the warning being displayed, and how to make it go away?

I'm hardly going to create a new issue for a D8 port of a module when there's a perfectly good existing issue for exactly that purpose. That would be silly.

Edit: Oh, you want everyone to create issues under this "Drupal 8 Contrib Porting Tracker" project, rather than in the issue queue for the actual project? That could be WAY more obvious -- who is going to assume that the D8 port issue for their project would be anywhere other than their project's issue queue?!

Edit: Fixed.

jweowu’s picture

Issue summary: View changes
loopduplicate’s picture

Issue summary: View changes
jweowu’s picture

Issue summary: View changes
webchick’s picture

Some of those questions are mentioned on the FAQ on the project page, so that's a good first place to start.

Basically, this is a "meta" project for tracking the porting statuses of all modules in a consistent way, and included non-technical details (like estimated release date, methods of funding developers, etc.) that don't really have a place in a technical issue tracker. All of the "meta" issues here should definitely link to the relevant D8 roadmap issue in a given project if it exists though!

webchick’s picture

Oh, and the messages go away once your module has a stable D8 release. :)

This new thing just got deployed this afternoon so we don't have that documented yet. Will add that to the FAQ as well.

jweowu’s picture

Issue summary: View changes
rcross’s picture

I'm not sure where it was decided to put a warning on all projects and then pointing to this issue/project, but it feels very heavy handed.

I have been following this project and really like/support it, but its a bit much to display an error on any project page that hasn't got a stable d8 release - even D8 isn't a stable release until nov 19th.

webchick’s picture

The implementation issue for that is over at #2573661: Show message linking users from project pages to the d8 contrib project.. I tried unsuccessfully to solicit wider opinions on the wording / icons before it was pushed live. Hopefully now that it's in everyone's face we can make some tweaks to still communicate what we need to (D8 porting status of projects on the project page; it's a total frigging mess out there right now; and encouraging developers towards rolling stable releases) but in a way that doesn't spook people off from D7.

jweowu’s picture

What status should be used for projects which aren't in D8 core, and which will never be ported to Drupal 8? It makes no sense at all to have any kind of D8 message displayed on those projects.

Should people just create and mark the issue here as "Fixed"? That doesn't seem right, as "Fixed / Closed (fixed) = Project has stable D8 release".

I feel that "Closed (works as designed)" could be used for this purpose (given that "won't fix" has been assigned a different meaning).

rcross’s picture

@jweowu - From this project's description, "Closed (Duplicate)" would be best as it indicates the module is obsolete. Also, you can leave it marked as "Active" to indicate that no D8 port has been started, and then leave it to someone else to port if/when they desire - creating an issue isn't a commitment to do the port yourself imho. Alternatively, I'd propose using "Closed (works as designed)" to indicate modules that are purely deprecated, but that is not part of the workflow at present.

webchick’s picture

We could repurpose "Closed (works as designed)", but curious why "Closed (duplicate)" wouldn't work? (Duplicate because ideally there's a suggestion in the ticket of what to use instead for people who were depending on that module in D7.)

jweowu’s picture

webchick: I was thinking more of the cases where no known Drupal 8 equivalent exists, and the maintainers have no interest whatsoever in ever dealing with Drupal 8 -- a perfectly valid choice which your current statuses really don't account for.

I suppose the "duplicate" status can still be used here, but with a "no known duplicate" message.

However it looks like you've stopped displaying a message on project pages for which no D8CPT issue has been created, so it's probably a moot point.

webchick’s picture

Ah, so like a "needs D8 maintainer" flag? That's not a bad idea.

There are still a couple of unused statuses we could utilize; for example, "Closed (cannot reproduce)" might be somewhat accurate. ;)

Kristen Pol’s picture

I like the idea of having a status for ones that just won't be ported even though the same functionality isn't available for D8. "Closed (won't fix)" seems semantically correct but that is being used for having the code in D8 core. I think "Closed (cannot reproduce)" might be confusing especially since we've been using that for a special status for issues that aren't for a project status. But, perhaps there's nothing better unless it's ok to overload the "Closed (won't fix)" for any project that won't be ported and doesn't have a contrib project to replace its functionality whether it's no longer maintained or it is in D8 core.

webchick’s picture

Well, I think it's more accurate to say "won't be ported by the current maintainer." It's all open source, so another person can always come along and port a module to D8, with or without the current maintainer's consent. (Though ideally, most maintainers would be eager to hand over commit access to someone willing to port the module to D8, but if not, there's always the clunky "/project/module_name2" approach or whatever.)

I know of at least one module in that position which is Webform. But the thing is, it's both "needs work" and also "seeking maintainer" so maybe an issue tag or some such for that status would be better.

webchick’s picture

And actually, one of the existing statuses that would work for @jweowu is "postponed (needs more info)" in that, "I'm definitely not doing it, and don't know who is, until we figure that out, it's not happening."

Kristen Pol’s picture

Title: [module_short_name] Module Human-Readable Name (Issue Template) » [project_short_name] Project Human-Readable Name (Issue Template)

Module => Project

mgifford’s picture

Issue summary: View changes
rbox’s picture

Title: [project_short_name] Project Human-Readable Name (Issue Template) » [background_process] Background Process
Assigned: Unassigned » rbox
Priority: Minor » Normal
Issue summary: View changes
Issue tags: +Drupal 8.x Port
rbox’s picture

Title: [background_process] Background Process » [project_short_name] Project Human-Readable Name (Issue Template)
Issue summary: View changes
rbox’s picture

Assigned: rbox » Unassigned
axel.rutz’s picture

Hmm, strange: This template seems not to have H3 tags, while most issues have. I guess for now i'll copy an issue, not this template...

jwilson3’s picture

As mentioned by axel.rutz ^ the format of the template appears to be Markdown.

How does one go about getting permissions to use that format so that I can properly clone the template for any projects I create?

And, secondly, why doesnt everyone get Markdown format automatically (if it does indeed exist, as i suspect)?

loopduplicate’s picture

Priority: Normal » Minor
Issue summary: View changes
Issue tags: -Drupal 8.x Port

Reverting to revision 10022911, the revision just before the accidental changes were made.

loopduplicate’s picture

Issue summary: View changes

Added link to Dreditor's github page.

bmunslow’s picture

Issue summary: View changes
bmunslow’s picture

Issue summary: View changes

Reverting back to previous revision, accidentally pasted new issue's text here.