mozilla / build.webmaker.org Goto Github PK
View Code? Open in Web Editor NEWSource behind MoFo's project tracking site
Home Page: https://build.webmaker.org
License: Mozilla Public License 2.0
Source behind MoFo's project tracking site
Home Page: https://build.webmaker.org
License: Mozilla Public License 2.0
"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.
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
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:
with some kind of bias or filtering to the repos we care most about right now.
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
We've noticed quite a bit of confusion over the "owner" title. We'd like to change it to "Driver".
I have been able to work on this project in the past, but it might have been pre-react.
I just did a fresh:
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
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:
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:
/cc @Pomax
Connect
500 TypeError: Object #<Object> has no method 'add'
at /app/server/controllers/schedule.js:29:15
at module.exports (/app/server/models/form.js:39:3)
at exports.createPost (/app/server/controllers/schedule.js:26:3)
at Layer.handle [as handle_request] (/app/node_modules/express/lib/router/layer.js:82:5)
at next (/app/node_modules/express/lib/router/route.js:110:13)
at Route.dispatch (/app/node_modules/express/lib/router/route.js:91:3)
at Layer.handle [as handle_request] (/app/node_modules/express/lib/router/layer.js:82:5)
at /app/node_modules/express/lib/router/index.js:267:22
at Function.proto.process_params (/app/node_modules/express/lib/router/index.js:321:12)
at next (/app/node_modules/express/lib/router/index.js:261:10)
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.
"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).
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.
When submitting the 'Add Project' form, generate child tickets for:
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:
Hey guys, not sure if this is the right place for issues like these, but the Hive badge is not found on webmaker.org
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.