Collaborators

[icebob]

Current collaborators

@icebob
@lionel-bijaoui
@dflock
@cristijora

Rules/Rights for collaborators

• create/close/modify/organize issues
• create/merge/close PRs
• Merge PRs only after @icebob approved!
• Open a discussion issue (and mention other collaborators) before create a new feature PR (need to discuss all new features with the team)

[icebob]

Welcome @cristijora as our new collaborator!

[cristijora]

Thanks!

[icebob]

Welcome @zoul0813 as our new collaborator!

[zoul0813]

Thanks @icebob

[lionel-bijaoui]

@icebob I would like to work on a v3 for VFG, can you create an branch for it ?

[icebob]

Yes. It's done.

[lionel-bijaoui]

Thank you !

[icebob]

Hi guys,

I automated the NPM publishing. Travis publishing the tagged commits. It means every collaborator can publish a new version to NPM (without me) :)
There is a new npm command to bump version, build files, tagging, and pushing.

For patch version (use after bug fixes)

$ npm run version patch

For minor version (use after new implemented features)

$ npm run version minor

For major version (use after breaking changes)

$ npm run version major

This executes the following tasks:

• bump version in package.json & bower.json
• npm run build so that dist files banner contains the new version number
• update CHANGELOG.md
• commit all changes files and push to Github
• create a new git tag & push to Github
• Travis will run publishing if tests successes

Result on Travis CI (only on Node 8 test):

Technical details:
It uses bumped to execute tasks & bump version.

VFG v2.2.1 has been released with this command.

[zoul0813]

The npm publish done by Travis will only occur if we bump the version - correct?

[icebob]

Yes, but the npm run version <type> bumps the version. So no need manually.
Travis doesn't check the version. It triggered by pushed git tags.

[zoul0813]

Ok, just making sure Travis wasn't going to automatically publish every commit to master. I assumed it wouldn't, but figured I'd ask just to double check.

[icebob]

No no.

[lionel-bijaoui]

What about merge ? Should we still wait for you approval @icebob ?

[icebob]

No, because I gave the project to the team. But I recommend that at least one other collaborator review all PRs, right?

[lionel-bijaoui]

That's fine by me, I just wanted to be sure about that. I remember this being a major rule to follow 😄

Maybe 2 other collaborator ?

[icebob]

Yes, but at that time I had enough free time to check all changes and issues. And now I haven't and I don't want to be the bottle-neck.

[icebob]

2 others is ok. But if no 2 other active collaborator after 2-3 days?

[lionel-bijaoui]

Yes, keep the thing rolling even if nobody answer.

So, if I create a PR :

• I add everyone for review.
• If I get 2 validations in less than 3 days, I can merge.
• If I get 1 validation in 3 days or more, I can merge.
• If I get a rejection, I can't merge as long as I haven't satisfied the demands. Even if I have 2 validations.
• If there is a conflict about a PR, everyone have to vote and discuss it to find a solution.
• The majority win if all else failed.

Does it sound fair ?

[lionel-bijaoui]

I have another question @icebob , what do we do about the modules ? Do I have the right to create a project under the organization ? How does that work ?
For example, how do I create @vue-form-generator/checklist ? What is the naming convention (@vue-form-generator/checklist or @vue-form-generator/fieldChecklist or @vue-form-generator/field-checklist) ?

[lionel-bijaoui]

Also, we should add a ISSUE_TEMPLATE.md to ask for a fiddle if this is a bug, expected vs observed behavior, etc.

[zoul0813]

I prefer the @vue-form-generator/field-checklist convention. Prefixing field components with field, so as not to confuse them with other possible modules we may come up with (validation modules, template/theme/style modules, etc). I prefer the kebab-case, personally.

As for the Fiddle, I think we need to update the current Fiddle referenced in the docs to use the latest VFG and Vue... and I agree, we should have something we can reference when requesting Fiddles for issues.

[icebob]

@lionel-bijaoui I think yes, you can create modules, but I don't know, it is my first org with other users :) So would be good to try it and if not working I will try to set the correct rights.
I prefer the @vue-form-generator/field-checklist type. Maybe in the future, we will have other types, like validator-xxx...etc

Yes, ISSUE template would be great. Could you make one?

[lionel-bijaoui]

I like this one
EDIT: #418

[icebob]

@lionel-bijaoui what is your npmjs.com username?

[lionel-bijaoui]

@icebob I don't have an account, let me create one
EDIT: https://www.npmjs.com/~lionel-bijaoui

[lionel-bijaoui]

About the naming convention, I forget that we decided vfg-field-*** (eg. @vue-form-generator/vfg-field-checklist)
We have our first external field #419 !

[zoul0813]

@lionel-bijaoui I noticed that we have a vfg demo and vfg examples repo. Can you explain what these are intended to be used for (looks like you set them up)?

I'm working on documentation updates and trying to close issues on VFG 2.x and am wondering if either the "demo" or "examples" repos can be used with JSFiddle's GitHub integration to host our dev/projects/ examples ... it looks like the examples project is possibly intended to do this, but at the moment that appears to just be a repo with the examples as is ... can I modify these to make them work with JSFiddle's GitHub integration (would require some file renaming, and a few updates)?