Simplify submission process

[ehammond]

Managing the creation of this document in Git/GitHub is a cool idea, but after doing it once, I see some drawbacks:

1. It is difficult to see if a pull request has already been created for the resource I am thinking of adding, especially since pull requests could take days to be merged into the primary repo.
2. It is a fair amount of work to fork, create a branch, clone, edit, commit, push, create pull request just to submit a line of text with a couple links.
3. I'm guessing that having 10 people submit pull requests to change the same "???" line in the Monday section creates a lot of conflicts and makes accepting all of the new submissions non-trivial.

Ideas?

Volunteer(s) to accept simplified submission proposals and incorporate into a unified pull request?

[rjhintz]

@ehammond Agreed. I've been experimenting with different way to do the branch->generate PR part without a lot of optimization presenting itself.

I was going to look around at other projects that have similar workflow, but perhaps you have something in mind?

[ehammond]

I've seen folks have decent success with Google Sheets open to editing. This was done for a community contributed AWS re:Invent after-hours event guide last year. It would need a little munging to get it into HTML unless folks are pasting raw HTML snippets.

[ehammond]

It seems to me that there are a number of phases to building an issue:

1. Identifying potential resources. Many people publishing resources would be happy to submit these if there were an easy way to do so. Some could be collected automatically through RSS feeds (e.g., AWS blogs). Some could be found by enterprising individuals who like contributing in this way.
2. Moderating/curating the submissions. Needs a trusted authority to make sure submissions are related to AWS and to avoid spam. I presume Jeff is mostly doing this now.
3. Formatting individual submissions into consistent HTML.
4. Combining all submissions into a single document.

[rjhintz]

I got as far as the first part of number 1 with a simple minded Google Form capturing the 4 data elements generally put in a list item. This populated a Google Sheet.

Number 2 needs human curation, as you note. Numbers 3 & 4 might possibly be automated from the Google Sheet, though keeping the headings used might be challenging.

[jeffbarr]

It has been a crazy week here in Seattle, as you may have been able to tell from my Twitter feed and the AWS Blog!

This is great feedback, by the way.

After merging far too many conflicting pull requests this evening I agree that there should be a better and easier way to do this. I have never run an open source project or used Git before and I have learned a lot about both. I wanted to get some experience with the initial process before refining it.

I do like the accountability that comes from having good identities via GitHub. I also believe that the user metrics that GitHub accumulates will create an incentive to participate.

Eric, it is possible to create a pull request completely within the browser, by the way. You simply click on Edit, make the change, and then fill in the details at the bottom.

I do have a very long list of RSS feeds that I pull from, and once tried to automate the creation of the initial WIR.

Let me give this one some more thought. I really appreciate the effort that the two of you are putting in to this.

[alexcasalboni]

@jeffbarr I think the best way would involve using a proper git flow and delegating the merge-task to each PR's author (who will have to keep his/her fork synced with your master repo). This probably means that a UI-only approach is not enough and the workflow would be a bit more complex for non-dev contributors.

Another alternative could be changing the files/folders structure completely. For example, each new submission could be one independent file (contained in a folder related to a specific day-of-the-week) and you will be able to compose all the files together with a simple automation script (e.g. a gulp task or a custom shell/Python script). This flow would ensure no git conflicts, although it would make duplicates detection harder.

[BackSpaceTech]

It sounds to me like GitHub is not the best way to go. This is probably a job for DynamoDB. Create an app to:

• Authenticate contributors using Amazon Oauth / Cognito.
• Create federated user credentials to access DynamoDB
• Accept submissions for the individual sections.
• Approvals process
• Notify contributor with SES if approved/not approved
• Create formatted HTML for the week in review page.

I can volunteer to do this as an open source project if you wish.

[rowanu]

Sorry guys, I think most of the proposed solutions here are over-engineered for what is a HTML page - so I'm going to propose another one 😄

Could submissions be done in plain text (i.e. individual files or CSV) format, and use a static site generator (like Hugo) to convert it and take care of ordering, formatting, etc?

[rjhintz]

Just to mention that as long as we keep the Github method, we probably should have more details on how to use Git workflow, similar to the detailed instructions in Chef's Community Contributions page. This will reduce the stray commits and, perhaps, make merges easier.

I'm not advocating keeping the Github method forever, just to make the current process more clear for those that don't use Git for public projects regularly.

[hyandell]

I discussed with @jeffbarr. The Week in Review is no longer being published. You can visit https://aws.amazon.com/new/ to track the latest product, service, and feature announcements from AWS.