mozilla / build.webmaker.org Goto Github PK

"How do you see, either in github on on build.wm.org, all the things that a person, say Ben, is working on?"

/cc @edrushka

For example, if you visit https://build.webmaker.org/now/ the page doesn't load. This can probably be resolved with a base tag or absolute links to resources.

For resourcing and even for understanding what an individual is attached to, it would be great to have a people-centric view of planning issues for a specific sprint (milestone).

For example, I currently don't have a simple way to see all issues in a sprint that @cassiemc is attached to (both P1 and P2). We could do this by parsing the RACI section, or even more simply, by extracting all @mentions from each issue body.

Right now /now has the stuff from the Jan 30 heartbeat, because we have unclosed issues in that milestone.

/cc @thisandagain

Would be cool, for example, to see which P1s are tied to the various platforms.

Add avatars or a nickname list to each issue in the /upcoming view for all users listed in the issue description.

Would be a welcome tweak 😄

cd plan is mentioned, but there isn't a plan directory in the root.

Need to turn on HTML5 history routing and then add specific routes on the server.

I saw this comment on Surman's blog post about the participation plan and think we should note it for a future iteration of build.w.o

BTW: I have seen https://build.webmaker.org/, but there was no explanation. What is webmaker? The text in “our mission” is very inexpressive. I would expect it to tell me really concrete, what it is about.

(after clicking some links I think I found out what’s the purpose: teaching people web-development to get them gain more web/internet/openness knowledge. But I’m still unsure.)

From @davidascher on January 16, 2015 19:40

e.g. issue titles are links. (as simple as underline on hover would be fine)

Copied from original issue: MozillaFoundation/plan#233

This can be done in the settings for the app. Looks like this:

Add 'file an issue against build.webmaker.org' quick link to the issues of build.webmaker.org. Kinda meta, but it took me a bit to find this repo to file an issue against.

Wouldn't use that wording, it seems a bit long.

I can see why someone might disagree with this, as it might seem like a 'file an issue' would be for webmaker.org in general. So that's something to work through.

As this is an internal website, we may as well make it easy for people to find the code & issues list, either in the footer or somewhere else people will look.

T'was working on the MozillaFoundation/plan repo, just need to copy those settings again. (Note: was also doing push-to-heroku on push-to-master).

via @secretrobotron

Intake form returns with an error when one of the fields is blank, but all previous entries are erased.

rage induced

If I navigate direct to /audience, I see this:

But it works if I get there via the nav from the homescreen.

An MVP could be a view on build.w.o which pulls in a list of:

• unassigned bugs
• or, bugs flagged 'good first bug'

with some kind of bias or filtering to the repos we care most about right now.

Should be "Lewis", not "Sadia".

Some people's avatars are not obvious. @edrushka, for instance: https://github.com/edrushka

I think the owners should be listed by Github name in addition to or instead of their photo.

Looking at: https://build.webmaker.org/now

Would be great to fit more issues on a single page. The vertical spacing between issues seems too wide. I think we could also decrease the size of the user photos, squeezing probably 4-5 more issues into a single view.

This makes a difference when I'm trying to get an overview of the heartbeat and make sense of how the work is connected.

build.w.o currently links to https://webmaker.org/en-US/getinvolved, which feels too shallow/broad; Clicking on code links to https://support.mozilla.org/en-US/kb/contribute-webmaker-code, which feels generally like a page we should review / throw away.

I'd suggest that if the visitor is aware of build.w.o, they're likely people we should involve directly in the production process (research, design, coding, etc.), and we should author a less wordy, more direct, and more "in-the-house" on-ramp to contributions we really want (and not, e.g. drive people to Popcorn).

Platform: Mac OS 10.10
Browser: Firefox Developer Edition

• "Home" is 2 pixels low and 1 - 2px to the right
• "Add Project" through "Upcoming" are 2 - 3px too high
• "Our Audience" is 2px to the right and 3 - 4px too high
• "Dashboard" is 1 - 2px too high
• "How We Work" is 2 - 3px too high
• "Get Involved" has incorrect indentation

We've noticed quite a bit of confusion over the "owner" title. We'd like to change it to "Driver".

/cc @OpenMatt @davidascher

I have been able to work on this project in the past, but it might have been pre-react.

I just did a fresh:

• clone
• npm insall
• gulp liveserve

Gulp runs as follows:

There's a bunch of JS style validation errors, but I don't think they are causing any problems.

If I then try to view the site, I get nothing:

I don't seem to ever get to the Server listening on port ..., even though Gulp does start serve:

[15:51:39] Starting 'serve'...
[15:51:39] Finished 'serve' after 40 ms

• Using Chartist.js for graphs in Dashboard as they appeal more.
• Website is not responsive as the text goes out of the screen.
• Space on RHS is wasted in "Upcoming" Tab.
• "This Sprint" and "Next Sprint" pages can be made in card style (similar to "Upcoming" Tab)

When I visit https://build.webmaker.org/ I get the home page, and something is wrong with the way the paragraph text is being displayed/rendered: many of the spaces between words are missing. For example, in the first sentence, "organization that" appears as "organizationthat".

To help you replicate this problem, here's what I was using:

Operating System: Mac OS X 10.10.2 (Yosemite)

Browsers: Firefox 36.0.1, Chrome 41.0.2272.76 (64-bit)

Extensions running in Firefox: ChatZilla, Disconnect, Facebook Disconnect, Google Disconnect, Twitter Disconnect

Browser extensions running in Chrome: Adblock Plus, Privacy Badger

"It’s super confusing trying to figure out who’s “included” (I don’t even know what the right term is) on each Repo. So when Cecile was trying to make a ticket in /plan (using build.wm.org), we couldn’t make @benrito the Decision Maker. Can you make it so EVERYONE can be on that list?"

Actionable immediately: make sure @benrito is in the group that is owners (which I think is MoFos)

"When we were trying to make smaller tickets in individual repos, Cecile didn’t have the ability to add milestones, labels etc. Why not, and how can we fix this?"

Immediately actionable step:

• figure out what repos @cecilepompei needs access to
• make sure @cecilepomei is on the teams that have admin access to said repos.

Right now none of the issues are understandable without more of the words written being shown. I'd say 2x as much body text.

(Ideally we'd have better titles too, but that's not a software bug).

So that we can add new features w/o accumulating debt.

We probably want to do it in a few phases:

• JS linting using mofo-standard ruleset
• change to new directory layout and browserification etc, but keep handlebars
• convert handlebars and server-side rendering to use react client-side views

/cc @Pomax

Fonts, logos, and other perennial assets would be useful collected on this site. Maintaining a collection like that can be messy and tedious. In the short-term, can we link to or embed our fledgling items on google drive? This collection should be kept minimal and avoid clutter.

@cassiemc

"When she used the form on build.webmaker.org it gave an error message. It took us a while to figure out you need text in each box. Can you make the error message text more descriptive?"

We end up with enough initiatives in /now for example that I kinda want to be able to sort & filter them when reviewing the plan on the first monday. Sort by tag, or sort by owner. And filter based on ideally everything (owner name, issue name, issue body, and label names).

e.g.:

(font is wrong, position within textbox is wrong)

From @davidascher on January 16, 2015 19:39

Likely to make issue descriptions more legible

Copied from original issue: MozillaFoundation/plan#232

Original issue:
MozillaFoundation/plan#202

cadecairos commented 5 days ago
I don't think it needs to read "All your information" and "read and write all public and private repos"

k88hudson commented 5 days ago
+1

thisandagain commented 4 days ago
:+1:

davidascher commented 4 days ago
I believe https://github.com/MozillaFoundation/plan/blob/master/app.js#L51 is the line that needs changing.

cadecairos commented 4 days ago
https://developer.github.com/v3/oauth/#scopes if all we need is access to public info, we can leave scopes blank.

So you can know when a heartbeat begins and ends, and so you know which heartbeat you are currently in.

If we start each issue with a clear goal, such as Matt's issue here: MozillaFoundation/plan#246 it creates a really lovely overview of the initiative on the Build site here: https://build.webmaker.org/now

This doesn't seem exactly the right repo to file this issue in, but I wonder if there is something in the Intake form that can optimize for this.

given that it applies to more things than just webmaker.

We might want to split the heartbeat related stuff from the product specific stuff -- move the former to build.mozillafoundation.org or some other site, and have build.webmaker be the stuff that's specific to the webmaker product, audience, etc. (and have it point to the new site for heartbeatish stuff)

I often have to refer to the work done in the previous heartbeat and have trouble locating the issues.

I get this when I try to add a new project using the form.

When submitting the 'Add Project' form, generate child tickets for:

1. Kick-off checklist(s)
2. Pre-flight checklist (hopefully one list for all projects, various QA sign-offs for dev, design, metrics, quality, etc)

Example metrics checklists:
https://github.com/mozilla/mofo-metrics/wiki/Metrics-Checklists

A Metrics Kick-off checklist is likely only relevant if users enter something for the 'How will you measure success?' field. This field should switch from being required to being optional to avoid generating lots of unnecessary child-tickets.

We should also decide which repos these tickets are filed in, and the UI for selecting this.

cc/ @davidascher

Anything else ends up looking wrong in the now/next views.

Might be a personal preference, but I use build.webmaker.org as my default issue list and am always opening new tabs from it.

"It is SO SO confusing that you have to make a meta-ticket in plan where the milestone is the heartbeat date, and then the individual tickets in the specific repo where you need to create a milestone that is the name of the meta-ticket (or whatever). This workflow is near-impossible for new people to grasp. Is Code Tree the solution? A tool that could visualize the relationships between meta-tickets in plan and smaller tickets in individual repos is desperately needed."

Proposed list:

• Metrics / Instrumentation
• Localization
• Design QA
• Functional QA

/cc @davidascher @simonwex @cassiemc @adamlofting @OpenMatt

Hey guys, not sure if this is the right place for issues like these, but the Hive badge is not found on webmaker.org

see: https://webmaker.org/badges/hive-community-member