Marked: Still the co-pilot. So, now what?

Created on 15 Feb 2018  路  18Comments  路  Source: markedjs/marked

All right, we have an org. I can see the settings tab - what now.

  1. This is the new home of Marked. Having said that, it's an organization account, which gives us more flexibility related to having more than just the Marked repo.
  2. We are sticking with the milestones already established; therefore, still considered in beta mode using the zero major to indicate that to the world: https://github.com/markedjs/marked/milestones
  3. We will use Travis CI for now as I believe @UziTech had plans and ways of doing this. Let me know what I can do to make that whole thing easier.
  4. @UziTech, @Feder1co5oave, and @styfle have been added as collaborators on the repo; this solves the PR merging problem. Recommend maintaining the master is always deployable (publishable to NPM) model. Please be considerate - again going back to the idea of having separate CONTRIBUTING, LICENSE, and CODE OF CONDUCT markdown files in the repo. I'm probably going to keep things strict for now and open as needed/requested.

About me. I am the owner of a company called 8fold. For my day job I am a consultant working on various IT projects and programs in various capacities. I've been looking for an excuse to start running CI with my own projects, but could not justify the expense - given that it's just me (a lot of my projects are private repos - guess I could have used some of the public one); however, I'm also testing out a new principle I would like to see become a bigger thing in the software development profession: If I create it, or acquire it, I help maintain it.

Marked and this crew are a good reason to start these experiments. Further, I'm helping another crew open source one of their internal projects and we are looking to use Circle CI for that as well - so, this is kind of like off the job training for me.

Built my first site in 1998...all I wanted to do was, what we now call UX, unfortunately, at the time, that term hadn't really become a thing; so, I sort of let myself get pushed into development. Now, I'm working toward being a coach on Agile Software Development teams after freelancing full time from 2007 to 2010 as an all around business consultant with a focus on UX and design. I'm also a value-based, principle-driven human; so, that's me. :)

Tagging in @chjj and @KostyaTretyak as well.

Most helpful comment

  1. I agree on keeping markedjs/marked.
  2. I would wait on the 1.0.0 release until we actually figure out what we want marked to be (slimmed down, beefed up, etc.). Stick with the milestones we already have set up.
  3. Include AppVeyor for Windows support to the CI (also free for OSPs).

All 18 comments

Very exciting to see that settings tab. Thanks @chjj!

I've created my fork to make good on the promises of modifying the contributors list:

https://docs.npmjs.com/files/package.json#default-values

"contributors": [...]
If there is an AUTHORS file in the root of your package, npm will treat each line as a Name <email> (url) format, where email and url are optional. Lines which start with a # or are blank, will be ignored.

I'm curious about this AUTHORS file - @UziTech, @Feder1co5oave, and @KostyaTretyak - do you want to hook me up, do it yourselves, or what??

Before we start adding contributors to the repo - think we should figure out our settings. I need to sleep though; so, we'll get it sorted in due time.

  1. Keep the repo as https://github.com/markedjs/marked/ (anything else seems to be misleading)
  2. Keep the npm package as https://www.npmjs.com/package/marked (do a 1.0.0 release when everything is transferred over and any changes are ready and polished)
  3. Travis/Circle CI are pretty comparable so either will work.

I don't think you'll need to spend any money for these 3 things since they provide free solutions for open source projects.

  1. I agree on keeping markedjs/marked.
  2. I would wait on the 1.0.0 release until we actually figure out what we want marked to be (slimmed down, beefed up, etc.). Stick with the milestones we already have set up.
  3. Include AppVeyor for Windows support to the CI (also free for OSPs).

CI is usually free for open source projects. I'm currently using Travis for testing on my fork.
Travis is also already set up and ready to work in #1020, you just need to sign up in travis and enable this repo after merging.
I'm currently working on integrating a cross-browser test system on the www.browserstack.com infrastructure. I've activated my free trial, but they say they provide free service for open source projects so I think we should submit a request for that in the future.
I don't see the need to set up also Appveyor to test on node on windows. It's up to you guys

I like the markedjs org, I don't understand what all the "billing" discussion was about.

It's a looooong way to 1.0.

I'm quite busy at the moment but I'm also working on many things for marked which will hopefully turn into PRs soon.

I'd _love_ to be added as a collaborator :blush:

Updated main content.

  1. Agreed, this seems like a good place so far.
  2. We should update package.json to point soon - I'm doing a lot today; so, sorry if this is terse and I'm unable to step up.
  3. Adding the three of you as collaborators - @styfle and @UziTech were both on the original fork 8fold had.

Note: If you would like to be removed as a collaborator let me know - not sure if you can remove yourself.

@joshbruce we're not ready to do CI yet, not until we merge the linting pr.
Can you cancel these builds
https://travis-ci.org/markedjs/marked/pull_request
and disable Travis momentarily? They've been running for more than an hour.

@joshbruce I created #1054 to fix the package.json

@Feder1co5oave: Looks like someone already beat me to it?? I only turned it on because I was having issues getting the repo to show up at all. lol

It wasn't me. I'm on the phone.

No worries. The PR @styfle did seems to not want to cancel. lol

I deleted the service entirely. My account with Travis got flagged as well; so, emailed them to let them know I was just being an idiot with a new toy. :)

Now that more of us have the ability to merge I've been thinking of how to handle release notes for the GitHub releases. Given the master is always deployable nature of things, I'm thinking a rolling release candidate concept could work.

  1. PR submitted
  2. PR reviewed and merged
  3. Update draft release notes with reference to PR
  4. Enough pull received for a release - perform NPM release process
  5. Finalize version number in draft release and release notes - publish release from master
  6. Create new draft release

Thoughts??

@styfle, @UziTech, @Feder1co5oave

Sounds good.
Question: is the draft shared by all the collaborators or private to the
one creating it?

@Feder1co5oave: Fair question. I think it's available for anyone who can see the repo, to be honest...but I am definitely not used to working in repos with multiple contributors; so, good to test things just to make sure.

There is a test draft release in place; so, if you can see it and edit it, we should be good to go; otherwise, will need to reconsider.

screen shot 2018-02-22 at 2 23 17 pm

I can see it and edit it. 馃憤

@joshbruce I'm closing this issue since there are already tickets addressing these issues.

See #1106 for continuity and backtracking

Was this page helpful?
0 / 5 - 0 ratings

Related issues

samit4me picture samit4me  路  3Comments

raguay picture raguay  路  4Comments

learykara picture learykara  路  3Comments

toc
zoe-cjf picture zoe-cjf  路  3Comments

amejiarosario picture amejiarosario  路  3Comments